JP2020174404A - 復号装置及び復号方法 - Google Patents

復号装置及び復号方法 Download PDF

Info

Publication number
JP2020174404A
JP2020174404A JP2020124518A JP2020124518A JP2020174404A JP 2020174404 A JP2020174404 A JP 2020174404A JP 2020124518 A JP2020124518 A JP 2020124518A JP 2020124518 A JP2020124518 A JP 2020124518A JP 2020174404 A JP2020174404 A JP 2020174404A
Authority
JP
Japan
Prior art keywords
reference clock
clock information
information
transmission
packet
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.)
Granted
Application number
JP2020124518A
Other languages
English (en)
Other versions
JP7038311B2 (ja
Inventor
賀敬 井口
Yoshitaka Iguchi
賀敬 井口
遠間 正真
Tadamasa Toma
正真 遠間
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Management Co Ltd
Original Assignee
Panasonic Intellectual Property Management Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Management Co Ltd filed Critical Panasonic Intellectual Property Management Co Ltd
Publication of JP2020174404A publication Critical patent/JP2020174404A/ja
Priority to JP2022022546A priority Critical patent/JP7257648B2/ja
Application granted granted Critical
Publication of JP7038311B2 publication Critical patent/JP7038311B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302Content synchronisation processes, e.g. decoder synchronisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】受信側で基準クロック情報を取得するための処理を軽減する。【解決手段】復号装置61な、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信部10と、前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置62に当該複数の第1の伝送単位を出力する復号部11とを備え、前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は基準クロック情報を含み、TMCC(Transmission and Multiplexing Configuration Control)制御情報の拡張領域は第2の基準クロック情報を含む。【選択図】図41

Description

本発明は、復号装置、逆多重化装置、復号方法及び逆多重化方法に関する。
MMT(MPEG Media Transport)方式(非特許文献1参照)は、映像及び音声などのコンテンツを多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。MMT方式を放送システムに適用する場合、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置におけるシステムクロックを生成する。
Information technology − High efficiency coding and media delivery in heterogeneous environment − Part1:MPEG media transport(MMT)、ISO/IEC DIS 23008−1 ARIB標準規格 ARIB STD−B44 (2.0版)、「高度広帯域衛星デジタル放送の伝送方式」、第3章「時刻情報の伝送に関するガイドライン」
送信側がMMTなどの多重化レイヤにおいて基準クロック情報の格納を行う場合、受信側で基準クロック情報を得るためには、多くの処理が必要であることが課題である。
本発明は、受信側で基準クロック情報を取得するための処理を軽減することができる復号装置、逆多重化装置、復号方法又は逆多重化方法を提供する。
本発明の一態様に係る復号装置は、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信部と、前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置に当該複数の第1の伝送単位を出力する復号部とを備え、前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は第1の基準クロック情報を含み、TMCC(Transmission and Multiplexing Configuration Control)制御情報の拡張領域は第2の基準クロック情報を含む。
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
本発明は、受信側で基準クロック情報を取得するための処理を軽減することができる復号装置、逆多重化装置、復号方法又は逆多重化方法を提供できる。
図1は、MMT方式及び高度BS伝送方式を用いて伝送を行う場合のプロトコルスタックを示す図である。 図2は、TLVパケットのデータ構造を示す図である。 図3は、受信装置の基本構成を示すブロック図である。 図4は、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図5は、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図6は、制御情報に基準クロック情報が格納される場合の受信装置の機能構成を示すブロック図である。 図7は、制御情報に基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図8は、TLVパケットに基準クロック情報が格納される場合の受信装置の構成を示すブロック図である。 図9は、ロングフォーマットNTPがTLVパケットに格納される例を示す図である。 図10は、TLVパケットに基準クロック情報が格納される場合の受信装置の基準クロック情報の取得フローを示す図である。 図11は、IPパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。 図12は、TLVパケットの直前に基準クロック情報が付加される構成を示す図である。 図13は、伝送スロットの構成を示す図である。 図14は、伝送スロットのスロットヘッダの構成を示す図である。 図15は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。 図16は、高度広帯域衛星デジタル放送の伝送方式におけるTMCC制御情報の構成を示す図である。 図17は、TMCC制御情報のストリーム種別/相対ストリーム情報を示す図である。 図18は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。 図19は、TMCC制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置の機能構成を示すブロック図である。 図20は、スロットヘッダに基準クロック情報を含むことを示す情報がTMCC制御情報に格納される場合の基準クロック情報の取得フローを示す図である。 図21は、IPパケットまたは圧縮IPパケットから特定位置のビット列を抽出する場合のフローを示す図である。 図22は、TMCC拡張情報の構成を示す図である。 図23は、このように分類された拡張種別が用いられた拡張領域のデータ構造の一例を示す図である。 図24は、拡張種別を使用する場合のシンタックスを示す図である。 図25は、実施の形態2に係る受信装置の機能構成を示すブロック図である。 図26は、実施の形態2に係る受信装置の動作フローを示す図である。 図27は、複数レイヤのそれぞれに基準クロック情報が格納される例を模式的に示す図である。 図28は、一つのレイヤに複数の基準クロック情報が格納される例を模式的に示す図である。 図29は、異なる放送局のデータがストリームに分けて格納される例を説明するためのブロック図である。 図30は、差分情報の送信方法を説明するための図である。 図31は、差分情報の送信方法の変形例を説明するための図である。 図32は、実施の形態3に係る受信装置の機能構成を示すブロック図である。 図33は、実施の形態3に係る受信装置の動作フローを示す図である。 図34は、実施の形態3に係る受信装置の別の動作フローを示す図である。 図35は、送信装置の機能構成を示すブロック図である。 図36は、送信装置の動作フローを示す図である。 図37は、実施の形態4に係る受信装置のブロック図である。 図38は、実施の形態4に係る主信号及び基準クロック情報のタイミングを示す図である。 図39は、実施の形態4に係る復号部における動作フローを示す図である。 図40は、実施の形態4に係る受信装置における動作フローを示す図である。 図41は、実施の形態4に係る上位レイヤにおける動作フローを示す図である。 図42は、実施の形態4に係る復号装置の動作フローを示す図である。 図43は、実施の形態4に係る逆多重化装置の動作フローを示す図である。
(本発明の基礎となった知見)
本発明は、MPEG(Moving Picture Expert Group)で規格化中のMMT方式を用いるハイブリッド配信システムにおいて、送信側から基準クロック情報を送信し、受信側で基準クロック情報を受信し、基準クロックを生成(再生)する方法及び装置に関する。
MMT方式は、映像及び音声を多重化及びパケット化し、放送または通信などの一つ以上の伝送路で送信するための多重化方式である。
MMT方式を放送システムに適用する場合、送信側の基準クロックをIETF RFC 5905に規定されるNTP(Network Time Protocol)に同期させ、基準クロックを基に、PTS(Presentation Time Stamp)や、DTS(Decode Time Stamp)などのタイムスタンプをメディアに付与する。さらに、送信側の基準クロック情報を受信側に送信し、受信装置では基準クロック情報を基に受信装置における基準クロック(以下、システムクロックとも記載する)を生成する。
放送システムでは、基準クロック情報として絶対時刻を示すことの可能な64ビットのロングフォーマットNTPが使用されることが望ましい。しかし、従来のMMT方式では、MMTパケットヘッダに32ビットのショートフォーマットNTPを格納して伝送することは規定されているが、ロングフォーマットNTPを伝送することは規定されておらず、受信機側で精度のよい基準クロック情報を取得することができない。
これに対し、メッセージ、テーブル、または記述子などの制御情報としてロングフォーマットNTPを定義し、制御情報にMMTパケットヘッダを付加して伝送することが可能である。この場合、MMTパケットは、IPパケットに格納されるなどして放送伝送路または通信伝送路を通じて伝送される。
MMTパケットをARIB規格で規定される高度BS伝送方式を用いて伝送する場合、MMTパケットをIPパケットへカプセル化し、IPパケットをTLV(Type Length Value)パケットへカプセル化した後、高度BS伝送方式で規定される伝送スロットへと格納する。
しかし、送信側においてMMTパケットのレイヤに基準クロック情報を格納した場合、受信側で基準クロック情報を得るためには、伝送スロットからTLVパケットを抽出し、TLVパケットからIPパケットを抽出し、IPパケットからMMTパケットを抽出し、さらにMMTパケットのヘッダまたはペイロードから基準クロック情報を抽出する、といった複数の処理が必要であり、基準クロック情報を取得するための処理が多く、さらに取得までにより多くの時間を要する。
また、IPレイヤ以上のレイヤにおける処理はソフトウェア処理であることが一般的であり、MMTパケットに基準クロック情報が格納されている場合、ソフトウェアプログラムによって基準クロック情報が抽出及び再生される。この場合、CPUの処理能力や、他のソフトウェアプログラムからの割り込みや優先度などによって、取得する基準クロック情報にジッタが生じることが課題である。
本発明の一態様に係る復号装置は、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信部と、前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置に当該複数の第1の伝送単位を出力する復号部とを備え、前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は基準クロック情報を含み、前記復号部は、さらに、前記先頭に位置する第1の伝送単位を特定するための情報を生成し、当該情報を前記逆多重化装置に出力する。
これにより、当該復号装置は、基準クロック情報を含む第1の伝送単位を特定するための情報を逆多重化装置に通知できる。これにより、逆多重化装置は、IPパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。
例えば、前記復号部は、前記先頭に位置する第1の伝送単位に格納される、当該第1の伝送単位の管理情報として、当該第1の伝送単位が前記基準クロック情報を含むことを示す前記情報を格納してもよい。
例えば、前記情報は、前記伝送用のフレーム内の複数の第1の伝送単位のうち、前記先頭に位置する第1の伝送単位を示す情報であってもよい。
例えば、前記複数の第1の伝送単位の各々は、前記コンテンツが格納されるIP(Internet Protocol)パケットを含んでもよい。
例えば、前記コンテンツは、前記IPパケット内のMMT(MPEG Media Transport)パケットに格納されてもよい。
例えば、前記第1の伝送単位は、可変長の伝送単位であり、前記第2の伝送単位は、固定長の伝送単位であってもよい。
例えば、前記第1の伝送単位は、TLV(Type Length Value)パケットであり、前記第2の伝送単位は、高度BS伝送方式におけるスロットであり、前記フレームは、高度BS伝送方式における伝送スロットであってもよい。
例えば、前記基準クロック情報は、NTP(Network Time Protocol)であってもよい。
本発明の一態様に係る逆多重化装置は、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを復号することで複数の前記第1の伝送単位を取得する復号装置から、当該複数の第1の伝送単位を取得する取得部と、前記複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化部とを備え、前記複数の第1の伝送単位の各々は、当該第1の伝送単位が基準クロック情報を含む場合には、当該当該第1の伝送単位が前記基準クロック情報を含むことを示す管理情報を含み、前記逆多重化部は、さらに、前記管理情報に基づき、前記基準クロック情報を含む第1の伝送単位を特定し、特定した第1の伝送単位から前記基準クロック情報を取得する。
これにより、当該逆多重化装置は、第1の伝送単位に含まれる管理情報に基づき、基準クロック情報を含む第1の伝送単位を特定できる。よって、当該逆多重化装置は、IPパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。
例えば、前記複数の第1の伝送単位の各々は、前記コンテンツが格納されるIP(Internet Protocol)パケットを含んでもよい。
例えば、前記コンテンツは、IPパケット内のMMT(MPEG Media Transport)パケットに格納されてもよい。
例えば、前記第1の伝送単位は、可変長の伝送単位であり、前記第2の伝送単位は、固定長の伝送単位であってもよい。
例えば、前記第1の伝送単位は、TLV(Type Length Value)パケットであり、前記第2の伝送単位は、高度BS伝送方式におけるスロットであり、前記フレームは、高度BS伝送方式における伝送スロットであってもよい。
例えば、前記基準クロック情報は、NTP(Network Time Protocol)であってもよい。
本発明の一態様に係る復号方法は、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信ステップと、前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置に当該複数の第1の伝送単位を出力する復号ステップとを含み、前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は基準クロック情報を含み、前記復号ステップでは、さらに、前記先頭に位置する第1の伝送単位を特定するための情報を生成し、当該情報を前記逆多重化装置に出力する。
これにより、当該復号方法は、基準クロック情報を含む第1の伝送単位を特定するための情報を逆多重化装置に通知できる。これにより、逆多重化装置は、IPパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。
本発明の一態様に係る逆多重化方法は、コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを復号することで複数の前記第1の伝送単位を取得する復号装置から、当該複数の第1の伝送単位を取得する取得ステップと、前記複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化ステップとを含み、前記複数の第1の伝送単位の各々は、当該第1の伝送単位が基準クロック情報を含む場合には、当該当該第1の伝送単位が前記基準クロック情報を含むことを示す管理情報を含み、前記逆多重化ステップでは、さらに、前記管理情報に基づき、前記基準クロック情報を含む第1の伝送単位を特定し、特定した第1の伝送単位から前記基準クロック情報を取得する。
これにより、当該逆多重化方法は、第1の伝送単位に含まれる管理情報に基づき、基準クロック情報を含む第1の伝送単位を特定できる。よって、当該逆多重化方法は、IPパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なCD−ROMなどの記録媒体で実現されてもよい。また、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。
以下、実施の形態について、図面を参照しながら具体的に説明する。
なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
(実施の形態1)
[MMT方式の基本的な構成]
まず、MMT方式の基本的な構成について説明する。図1は、MMT方式及び高度BS伝送方式を用いて伝送を行う場合のプロトコルスタック図を示す。
MMT方式では、映像や音声などの情報を、複数のMPU(Media Presentation Unit)や複数のMFU(Media Fragment Unit)に格納し、MMTパケットヘッダを付与してMMTパケット化する。
一方、MMT方式では、MMTメッセージなどの制御情報に対してもMMTパケットヘッダを付与し、MMTパケット化する。MMTパケットヘッダには、32ビットのショートフォーマットのNTPを格納するフィールドが設けられており、このフィールドは、通信回線のQoS制御等に用いることができる。
MMTパケット化されたデータは、UDPヘッダまたはIPヘッダを有するIPパケットにカプセル化される。このとき、IPヘッダまたはUDPヘッダにおいて、送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が同じパケットの集合をIPデータフローとした場合、1つのIPデータフローに含まれる複数のIPパケットは、ヘッダが冗長である。このため、1つのIPデータフローにおいては、一部のIPパケットは、ヘッダ圧縮される。
次に、TLVパケットについて詳細に説明する。図2は、TLVパケットのデータ構造を示す図である。
TLVパケットには、図2に示されるように、IPv4パケット、IPv6パケット、圧縮IPパケット、NULLパケット、及び、伝送制御信号が格納される。これらの情報は、8ビットのデータタイプを用いて識別される。伝送制御信号には、例えばAMT(Address Map Table)、及び、NIT(Network Information Table)などがある。また、TLVパケットにおいては、16ビットのフィールドを用いてデータ長(バイト単位)が示され、そのあとにデータの値が格納される。データタイプの前には1バイトのヘッダ情報がある(図2において図示せず)ため、TLVパケットは、合計4バイトのヘッダ領域を有する。
TLVパケットは、高度BS伝送方式における伝送スロットにマッピングされ、TMCC(Transmission and Multiplexing Configuration Control)制御情報(制御信号)に、スロット毎に包含される最初のパケットの先頭位置と最後のパケットの末尾の位置を示すポインタ/スロット情報が格納される。
次に、MMTパケットを高度BS伝送方式を用いて伝送する場合の受信装置の構成について説明する。図3は、受信装置の基本構成を示すブロック図である。なお、図3の受信装置の構成は、簡略化されたものであり、より具体的な構成については、基準クロック情報が格納される態様に応じて個別に後述される。
受信装置20は、受信部10と、復号部11と、TLVデマルチプレクサ(DEMUX)12と、IPデマルチプレクサ(DEMUX)13と、MMTデマルチプレクサ(DEMUX)14とを備える。
受信部10は、伝送路符号化データを受信する。
復号部11は、受信部10によって受信された伝送路符号化データを復号し、誤り訂正などを施し、TMCC制御情報、及び、TLVデータを抽出する。復号部11によって抽出されたTLVデータは、TLVデマルチプレクサ12によってDEMUX処理される。
TLVデマルチプレクサ12のDEMUX処理は、データタイプに応じて異なる。例えば、データタイプが圧縮IPパケットである場合は、TLVデマルチプレクサ12は、圧縮されたヘッダを復元してIPレイヤに渡すなどの処理を行う。
IPデマルチプレクサ13は、IPパケットまたはUDPパケットのヘッダ解析などの処理を行い、IPデータフロー毎にMMTパケットを抽出する。
MMTデマルチプレクサ14では、MMTパケットヘッダに格納されているパケットIDを基にフィルタリング処理(MMTパケットフィルタリング)を行う。
[MMTパケットに基準クロック情報を格納する方法]
上記図1〜図3を用いて説明したMMT方式では、MMTパケットヘッダに32ビットのショートフォーマットNTPを格納して伝送することができるが、ロングフォーマットNTPを伝送する方法は存在しない。
以下、MMTパケットに基準クロック情報を格納する方法について説明する。まず、MMTパケット内に基準クロック情報を格納する方法について説明する。
基準クロック情報を格納するための記述子、テーブル、またはメッセージを定義し、制御情報としてMMTパケットに格納する場合、基準クロック情報を示す記述子やテーブル、またはメッセージであることを示す識別子が制御情報内に示される。そして、制御情報は、送信側においてMMTパケットに格納される。
これにより、受信装置20は、識別子を基に基準クロック情報を識別することができる。なお、既存のディスクリプタ(例えば、CRI_descriptor()等)を用いることによって、基準クロック情報がMMTパケットに格納されてもよい。
次に、MMTパケットヘッダに基準クロック情報を格納する方法について説明する。
例えば、header_extensionフィールド(以下拡張フィールドと記載する。)を用いて格納する方法がある。拡張フィールドは、MMTパケットヘッダのextension_flagを’1’とすることで有効になる。
拡張フィールドには、拡張フィールドに格納するデータのデータ種別を示す拡張フィールドタイプを格納し、拡張フィールドタイプに、基準クロック情報(例えば、64ビットのロングフォーマットNTP)であることを示す情報を格納し、拡張フィールドに基準クロック情報を格納する方法がある。
この場合、受信装置20は、MMTパケットヘッダのheader_extension_flagが’1’となっている場合は、MMTパケットの拡張フィールドを参照する。拡張フィールドタイプに基準クロック情報であることが示されている場合には、基準クロック情報を抽出し、クロックを再生する。
なお、基準クロック情報は、既存のヘッダフィールドに格納されてもよい。また、未使用のフィールドがある場合や、放送に必要のないフィールドがある場合、これらのフィールドに基準クロック情報が格納されてもよい。
また、基準クロック情報は、既存のフィールドと拡張フィールドとを併用して格納されてもよい。例えば、既存の32bitショートフォーマットNTPフィールドと拡張フィールドとが併用されてもよい。
既存フィールドと互換性を保つために、64bitロングフォーマットNTPのうち、ショートフォーマットのフォーマットに対応する32bit部分のみが既存フィールドに格納され、残りの32bitが拡張フィールドに格納されてもよい。
なお、基準クロック情報は、例えば、基準クロック情報が格納されるMMTパケットの先頭のビットが所定の位置を通過するとき(例えば、送信装置の特定の構成要素から出力されるとき)の時刻であるが、他の位置のビットが所定の位置を通過するときの時刻であってもよい。
基準クロック情報が制御情報としてMMTパケットに格納される場合、制御情報を含むMMTパケットは、所定の送信間隔で送信される。
基準クロック情報がMMTパケットの拡張フィールドに格納される場合は、所定のMMTパケットのヘッダの拡張フィールドに格納される。具体的には、例えば、基準クロック情報は、100ms間隔で少なくとも1つ以上、MMTパケットのヘッダ拡張フィールドに格納される。
なお、MMTパケットに基準クロック情報が格納される場合、プログラム情報には、基準クロック情報が格納されているMMTのパケットIDが格納される。受信装置20は、プログラム情報を解析し、基準クロック情報が格納されたMMTパケットを取得する。このとき、基準クロック情報が格納されたMMTパケットのパケットIDは、あらかじめ固定値として規定されてもよい。これにより、受信装置20は、プログラム情報を解析することなく基準クロック情報を取得できる。
[MMTパケットに基準クロック情報を格納した場合の動作フロー]
次に、MMTパケットに基準クロック情報を格納した場合の動作フロー(基準クロック情報の取得フロー)について説明する。
まず、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置20の基準クロック情報の取得フローについて説明する。図4は、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置20の機能構成を示すブロック図である。図5は、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合の受信装置20の基準クロック情報の取得フローを示す図である。
図4に示されるように、MMTパケットヘッダの拡張フィールドに基準クロック情報が格納される場合、MMTデマルチプレクサ14内には、基準クロック情報抽出部15(抽出部の一例)が設けられ、MMTデマルチプレクサ14の後段には、基準クロック生成部16(生成部の一例)が設けられる。
図5のフローにおいて、受信装置20の復号部11は、受信部10が受信した伝送路符号化データを復号し(S101)、伝送スロットからTLVパケットを抽出する(S102)。
次に、TLVデマルチプレクサ12は、抽出されたTLVパケットをDEMUXし、IPパケットを抽出する(S103)。このとき、圧縮IPパケットのヘッダが再生される。
次に、IPデマルチプレクサ13は、IPパケットをDEMUXし、指定されたIPデータフローを取得し、MMTパケットを抽出する(S104)。
次に、MMTデマルチプレクサ14は、MMTパケットのヘッダを解析し、拡張フィールドが使用されているかどうか、拡張フィールドに基準クロック情報があるかどうかの判定を行う(S106)。拡張フィールドに基準クロック情報がない場合は(S106でNo)、処理を終了する。
一方、拡張フィールドに基準クロック情報があると判定された場合(S106でYes)、基準クロック情報抽出部15は、拡張フィールドから基準クロック情報を抽出する(S107)。そして、基準クロック生成部16は、抽出された基準クロック情報を基にシステムクロックを生成する(S108)。システムクロックは、言い換えれば、コンテンツを再生するためのクロックである。
次に、制御情報に基準クロック情報が格納される場合の受信装置20の基準クロック情報の取得フローについて説明する。図6は、制御情報に基準クロック情報が格納される場合の受信装置20の機能構成を示すブロック図である。図7は、制御情報に基準クロック情報が格納される場合の受信装置20の基準クロック情報の取得フローを示す図である。
図6に示されるように、制御情報に基準クロック情報が格納される場合、基準クロック情報抽出部15は、MMTデマルチプレクサ14の後段に配置される。
図7のフローにおいて、ステップS111〜ステップS114の処理は、図5で説明したステップS101〜ステップS104のフローと同一である。
ステップS114に続いて、MMTデマルチプレクサ14は、プログラム情報から基準クロック情報を含むパケットのパケットIDを取得し(S115)、当該パケットIDのMMTパケットを取得する(S116)。続いて、基準クロック情報抽出部15は、抽出したMMTパケットに含まれる制御信号から基準クロック情報を抽出し(S117)、基準クロック生成部16は、抽出された基準クロック情報を基にシステムクロックを生成する(S118)。
[TLVパケットに基準クロック情報を格納する方法]
図5及び図7で説明したように、MMTパケットに基準クロック情報が格納される場合、受信側で基準クロック情報を得るためには、受信装置20は、伝送スロットからTLVパケットを抽出し、TLVパケットからIPパケットを抽出する。さらに、受信装置20は、IPパケットからMMTパケットを抽出し、さらにMMTパケットのヘッダまたはペイロードから基準クロック情報を抽出する。このように、MMTパケットに基準クロック情報が格納される場合、基準クロック情報を取得するための処理が多く、さらに取得までに多くの時間を要することが課題である。
そこで、基準クロックを基に映像や音声などのメディアにタイムスタンプを付与する処理及びメディアを伝送する処理は、MMT方式を用いて実現し、かつ、基準クロック情報の伝送を、MMTレイヤよりも下位のレイヤ、下位のプロトコル、または下位の多重化方式を用いて行う方法について説明する。
まず、TLVパケットに基準クロック情報を格納して伝送する方法について説明する。図8は、TLVパケットに基準クロック情報が格納される場合の受信装置20の構成を示すブロック図である。
図8に示される受信装置20では、基準クロック情報抽出部15と、基準クロック生成部16との配置が図4及び図6と異なる。また、図8では同期部17及び復号提示部18も図示されている。
TLVパケットの構成は、上記図2に示されるように、8ビットのデータタイプ、16ビットのデータ長、及び8*Nビットのデータから構成される。また、上述のようにデータタイプの前には、図2において図示されない1バイトのヘッダが存在する。なお、データタイプは、具体的には、例えば、0x01:IPv4パケット、0x03:ヘッダ圧縮したIPパケットなどと規定される。
新規のデータをTLVパケットに格納するために、データタイプの未定義領域を用いてデータタイプが規定される。TLVパケットに基準クロック情報が格納されていることを示すために、データタイプには、データが基準クロック情報であることを示す記述がなされる。
なお、データタイプは、基準クロックの種類毎に規定されてもよい。例えば、ショートフォーマットNTP、ロングフォーマットNTP、及びPCR(Program Clock Reference)を示すデータタイプがそれぞれ個別に規定されてもよい。図9は、ロングフォーマットNTPがTLVパケットに格納される例を示す図であり、ロングフォーマットNTPは、データフィールドに格納されている。
この場合、基準クロック情報抽出部15は、TLVパケットのデータタイプを解析し、基準クロック情報が格納されている場合には、データ長を解析し、データフィールドから基準クロック情報を抽出する。
なお、データタイプによって、データ長が一意に決定されている場合、基準クロック情報抽出部15は、データ長フィールドを解析することなく基準クロック情報を取得してもよい。例えば、データタイプが64bitロングローマットNTPであることが示されている場合、基準クロック情報抽出部15は、4バイト+1ビット目から4バイト+64ビット目までを抽出してもよい。また、基準クロック情報抽出部15は、64bitのデータから、所望のビットだけを抽出してもよい。
次に、TLVパケットに基準クロック情報が格納される場合の受信装置20の動作フロー(基準クロック情報の取得フロー)について、図10を用いて説明する。図10は、TLVパケットに基準クロック情報が格納される場合の受信装置20の基準クロック情報の取得フローを示す図である。
図10のフローにおいては、まず、復号部11は、受信部10が受信した伝送路符号化データを復号し(S121)、伝送スロットからTLVパケットを抽出する(S122)。
次に、TLVデマルチプレクサ12は、TLVパケットのデータタイプを解析し(S123)、データタイプが基準クロック情報であるかどうかの判定を行う(S124)。データタイプが基準クロックである場合は(S124でYes)、基準クロック情報抽出部15は、TLVパケットのデータフィールドから基準クロック情報を抽出する(S125)。そして、基準クロック生成部16は、基準クロック情報を基に、システムクロックを生成する(S126)。一方、データタイプが基準クロック情報でない場合は(S124でNo)、基準クロック情報の取得フローは終了する。
また、図示されないフローにおいて、IPデマルチプレクサ13は、データタイプに応じてIPパケットを抽出する。そして、抽出されたIPパケットに対してIP DEMUX処理、及びMMT DEMUX処理が行われてMMTパケットが抽出される。さらに、同期部17は、抽出されたMMTパケットに含まれる映像データのタイムスタンプがステップS126で生成された基準クロックに一致するタイミングで復号提示部18に当該映像データを出力し、復号提示部18は、映像データを復号及び提示する。
以上説明した送信方法では、TLVパケットのタイプデータにおいて基準クロック情報を格納していることが示され、TLVパケットのデータフィールドに基準クロック情報が格納される。このように、MMTレイヤよりも下位のレイヤまたは下位のプロトコルを用いて基準クロック情報を格納し、送信することにより、受信装置20における基準クロック情報を抽出するまでの処理や時間を削減することができる。
また、IPレイヤにまたがって、より下位のレイヤで基準クロック情報が抽出・再生できるため、基準クロック情報の抽出をハードウェア実装により行うことができる。これにより、基準クロック情報の抽出をソフトウェア実装により行う場合よりもジッタなどの影響を軽減することができ、より高精度な基準クロックを生成することが可能となる。
次に、基準クロック情報を格納するその他の方法について説明する。
上記図10のフローにおいて、データタイプによってデータ長が一意に決定される場合、データ長フィールドは、送信されなくてもよい。なお、データ長フィールドが送信されない場合は、データ長フィールドが送信されないデータであることを示す識別子が格納される。
また、図10の説明では、基準クロック情報は、TLVパケットのデータフィールドに格納されたが、基準クロック情報は、TLVパケットの直前や直後に付加されてもよい。また、基準クロック情報は、TLVパケットに格納されるデータの直前や直後に付加されてもよい。これらの場合、基準クロック情報が付加されている場所を特定できるようなデータタイプが付与される。
例えば、図11は、IPパケットのヘッダの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは、基準クロック情報付IPパケットであることを示す。受信装置20(基準クロック情報抽出部15)は、データタイプが基準クロック情報付IPパケットであること示す場合、TLVパケットのデータフィールドの先頭から、あらかじめ定めされた所定の基準クロック情報の長さのビットを抽出することにより、基準クロック情報を取得できる。このとき、データ長は、基準クロック情報の長さを含むデータの長さを指定してもよいし、基準クロック情報の長さを含まない長さを指定してもよい。データ長に基準クロック情報の長さを含むデータの長さが指定されている場合、受信装置20(基準クロック情報抽出部15)は、データ長から基準クロック情報の長さを減算した長さのデータを基準クロック情報の直後から取得する。データ長に基準クロック情報の長さを含まないデータの長さが指定されている場合、受信装置20(基準クロック情報抽出部15)は、データ長に指定されている長さのデータを基準クロック情報の直後から取得する。
また、図12は、TLVパケットの直前に基準クロック情報が付加される構成を示す図である。この場合、データタイプは従来通りのデータタイプとし、TLVパケットが基準クロック情報付TLVパケットであること示す識別子が、例えば、伝送スロットのスロットヘッダまたはTMCC制御情報に格納される。図13は、伝送スロットの構成を示す図であり、図14は、伝送スロットのスロットヘッダの構成を示す図である。
図13に示されるように、伝送スロットは、複数のスロット(図13の例では、Slot#1−Slot#120の120個のスロット)から構成される。各スロットに含まれるビット数は、誤り訂正の符号化率に基づいて一意に定められた固定ビット数であり、スロットヘッダを有し、1以上のTLVパケットが格納される。なお、図13に示されるように、TLVパケットは、可変長である。
図14に示されるように、スロットヘッダの先頭TLV指示フィールド(16bits)には、スロット中の最初のTLVパケットの先頭バイトの位置を、スロットヘッダを除いたスロット先頭からのバイト数で示したものが格納される。スロットヘッダの残りの160bitsは、未定義である。伝送スロットは、上述のように1フレームあたり120個のスロットで構成され、スロットへの変調方式の割り当ては5スロット単位である。また、1フレーム内では最大16のストリームを伝送可能である。なお、1つの伝送スロットに含まれる複数のストリームは、例えば、当該ストリームによって伝送されるコンテンツ(または、コンテンツを提供する事業者)が互いに異なる。また、ストリームは、1以上のスロットで構成され、1つのスロットが複数のストリームにまたがることはない。
TLVパケットが基準クロック情報付TLVパケットであること示す識別子が、スロットヘッダに格納される場合、例えば、スロット内において基準クロック情報付TLVパケットの位置を特定できる情報、基準クロック情報の種類、及びデータ長などが、スロットヘッダの未定義フィールドを拡張(利用)して格納される。
なお、基準クロック情報付TLVパケットの位置を特定できる情報、基準クロック情報の種類、及び、データ長のすべての情報がスロットヘッダに格納されていなくてもよい。基準クロック情報付TLVパケットを特定及び参照することができる情報が示されていればよい。
例えば、基準クロック情報が、64ビットロングフォーマットNTPであり、1つのスロットに格納できる基準クロック情報付TLVパケットは1つであり、かつ、必ず先頭のTLVパケットであると定義される場合、スロットヘッダの未定義領域にフラグが格納されてもよい。図15は、スロットヘッダの未定義領域にフラグが格納される例を示す図である。
図15の例では、スロットヘッダの未定義領域に、当該スロットに基準クロック情報が含まれているかどうか示すフラグ(図中で「F」と記載)が格納されている。このようなフラグによって、受信装置20は、先頭のTLVパケットが基準クロック情報付TLVパケットであると判断してもよい。
また、TLVパケットが基準クロック情報付TLVパケットであること示す識別子(情報)は、TMCC制御情報に格納されてもよい。図16は、高度広帯域衛星デジタル放送の伝送方式におけるTMCC制御情報の構成を示す図である。
基準クロック情報付TLVパケットを特定及び参照するための情報は、図16に示されるTMCC制御情報内の拡張情報に格納されてもよいし、TMCC制御情報内のその他の場所に格納されてもよい。例えば、TMCC制御情報のストリーム種別/相対ストリーム情報が、基準クロック情報付TLVパケットを特定及び参照するための情報として使用されてもよい。図17は、TMCC制御情報のストリーム種別/相対ストリーム情報を示す図である。
図17に示されるように、ストリーム種別/相対ストリーム情報においては、16本のストリーム毎のストリーム種別が8ビットで示される。つまり、1フレームの伝送スロットによれば、最大16本(16種別)のストリームを伝送することができる。例えば、MPEG2−TSストリームのストリーム種別は、「00000000」であり、TLVストリームのストリーム種別は、「00000010」である。しかしながら、その他のストリームに対しては、現状、割り当て種別なし又は未定義である。
そこで、基準クロック付TLVストリームのストリーム種別を、例えば「00000100」と定義し、相対ストリームが基準クロック付TLVストリームである場合には、TMCC制御情報のストリーム種別/相対ストリーム情報に「00000100」を格納する。ここで、ストリーム種別が「00000100」となっているストリームにおいては、例えば、スロット割り当て単位である5スロット単位に一回、または、フレーム単位に一回、基準クロック情報を含むTLVパケットが格納される。
このような構成においては、受信装置20は、TMCC制御情報のストリーム種別/相対ストリーム情報を解析し、ストリーム種別が「00000100」となっている場合、あらかじめ定められたスロットから基準クロック付TLVパケットを取得する。
なお、ダウンロード型TLVパケットを含むストリーム種別と、映像や音声などのストリーム型TLVパケットを含むストリーム種別とが定義される場合が考えられる。このような場合、受信装置20は、受信したストリームのストリーム種別が、ストリーム型TLVパケットであるときに、ストリームに基準クロック情報が含まれると判断してもよい。なぜなら、ダウンロード型のTLVパケットの再生においては、通常、基準クロック情報は用いられないからである。
また、基準クロック情報付TLVパケットを特定及び参照するための情報がTMCC制御情報の拡張情報に格納される場合は、例えば、16本の相対ストリーム毎の情報がTMCC制御情報の拡張領域に格納される。
また、図18に示されるように、スロットヘッダの未定義フィールドに基準クロック情報が格納される領域が新たに定義されてもよい。図18は、スロットヘッダの未定義フィールドに基準クロック情報が格納される例を示す図である。
また、あらかじめ定められたスロットに基準クロック情報が格納されてもよいし、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納されてもよい。ここで、あらかじめ定められたスロットは、例えば、伝送スロットのうちの先頭のスロット(図13の例ではSlot#1)であり、このスロット内の先頭のTLVパケットにIPパケットに格納された基準クロック情報が含まれてもよい。また、伝送スロットに複数のストリームが含まれる場合、あらかじめ定められたスロットは、例えば、伝送スロットに含まれる各ストリームの先頭のスロットであり、このスロット内の先頭のTLVパケットにIPパケットに格納された基準クロック情報が含まれてもよい。
また、TMCC制御情報には、基準クロック情報を含むスロットヘッダを特定し参照するための情報が格納されてもよい。なお、基準クロック情報を含むスロットヘッダを特定及び参照するための情報のTMCC制御情報への格納方法は、上述した基準クロック情報付TLVパケットを特定及び参照するための情報の格納方法と同様であるため、説明が省略される。
この場合、受信装置20は、TMCC制御情報を解析し、スロットヘッダに基準クロック情報があると判定した場合には、スロットヘッダから基準クロック情報を抽出する。
また、TMCC制御情報に基準クロック情報を含むことを示す情報が格納されてもよい。図19は、TMCC制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置20の機能構成を示すブロック図である。図20は、スロットヘッダに基準クロック情報を含むことを示す情報がTMCC制御情報に格納される場合の基準クロック情報の取得フローである。
図19に示されるように、TMCC制御情報に、スロットヘッダ内に基準クロック情報を含むことを示す情報が格納される場合の受信装置20においては、基準クロック情報抽出部15は、復号部11から出力される伝送スロットから基準クロック信号を取得する。
図20のフローでは、復号部11は、伝送路符号化データを復号し(S131)、TMCC制御情報を解析し(S132)、伝送スロット内のスロットヘッダに基準クロック情報があるかどうかを判定する(S133)。スロットヘッダに基準クロック情報がある場合は(S133でYes)、基準クロック情報抽出部15は、スロットヘッダから基準クロック情報を抽出し(S134)、基準クロック生成部16は、基準クロック情報を基にシステムの基準クロック(システムクロック)を生成する(S135)。一方、スロットヘッダに基準クロック情報がない場合は(S133でNo)、基準クロック情報の取得フローは終了する。
このような受信装置20は、伝送スロットのレイヤで基準クロック情報を取得することができるため、TLVパケットに格納する場合よりもさらに早く基準クロック情報を取得できる。
以上説明したように、TLVパケットや伝送スロットに基準クロック情報を格納することにより、受信装置20において、基準クロック情報を取得するまでの処理を軽減することができ、かつ、基準クロック情報の取得時間を短縮できる。
また、このように、物理レイヤにおいて基準クロック情報が格納されることにより、ハードウェアによる基準クロック情報の取得及び再生が容易に実現でき、ソフトウェアによる基準クロック情報の取得及び再生よりも精度の高いクロック再生が可能である。
また、上記実施の形態1に係る送信方法は、まとめると、IPレイヤを含む複数のレイヤ(プロトコル)が存在するシステムにおいて、IPレイヤより上位のレイヤで基準クロック情報を基にメディアのタイムスタンプを付与し、IPレイヤより下位のレイヤで基準クロック情報を送信する。このような構成によれば、受信装置20において基準クロック情報をハードウェアで処理することが容易となる。
なお、同様の思想に基づき、IPパケット内にMMTパケットに格納されない状態で基準クロック情報を格納することも考えられる。このような場合であっても、MMTパケットに基準クロック情報が格納される場合よりも、基準クロック情報を取得するための処理を軽減することができる。
[基準クロック情報の送出周期]
以下、基準クロック情報の送出周期について補足する。
TLVパケットに基準クロック情報を格納する場合、例えば、送信側においてTLVパケットの先頭のビットが送出される時刻を基準クロック情報として格納する。また、先頭のビットの送出時刻ではなく、他に定められた所定の時刻が基準クロック情報として格納されてもよい。
基準クロック情報を含むTLVパケットは、所定の間隔で送信される。言い換えれば、基準クロック情報を含むTLVパケットは、伝送スロットに含まれて所定の送信周期で送信される。例えば、基準クロック情報は、100ms間隔に少なくとも1つ以上、TLVパケットに格納されて伝送されてもよい。
また、高度BS伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むTLVパケットが配置されてもよい。また、TLVパケットのスロット割り当て単位である5スロット単位毎に一回、基準クロック情報を含むTLVパケットが格納され、5スロット単位のうち一番初めのスロットの先頭のTLVパケットに基準クロック情報が格納されてもよい。すなわち、伝送スロット内の先頭のスロット内の先頭(つまり、スロットヘッダの直後)に、基準クロック情報を含むTLVパケットが配置されてもよい。
また、高度広帯域衛星デジタル放送の伝送方式の伝送スロットの所定の場所に、所定の間隔で基準クロック情報を含むTLVパケットが配置されてもよい。例えば、スロット割り当て単位である5スロット単位にごとに一回、基準クロック情報が一番初めのスロットの先頭のTLVパケットに格納されてもよい。すなわち、伝送スロットに含まれる各ストリームの先頭のスロット内で先頭に位置するTLVパケットに、基準クロック情報が含まれてもよい。また、基準クロック情報は、相対ストリームの中で1番目のスロットに格納されてもよい。
また、基準クロック情報の送出周期及び送出間隔は、伝送路符号化方式の変調方式または符号化率に応じて変更されてもよい。
[上位レイヤの基準クロック情報を早く取得する方法]
次に、受信装置20において下位レイヤから上位レイヤまでのDEMUXを一括で処理することにより、基準クロック情報の取得までの時間を短縮する方法について説明する。
ここでは、MMTパケットなどの上位レイヤに基準クロック情報を格納し、基準クロック情報が格納されたMMTパケットをIPパケットに格納する方法について説明する。以下で説明する方法では、基準クロック情報が格納されたIPパケットをTLVパケットに格納するためのプロトコルを定義することにより、TLVパケットのような下位レイヤから、上位レイヤであるMMTパケットを直接参照し、通常のDEMUX処理をすることなくMMTパケットに含まれる基準クロック情報を取得する。
送信側において、基準クロック情報は、上述のMMTパケットに格納される制御情報に含まれる。基準クロック情報を含む制御情報には、あらかじめ定められたパケットIDが付与される。そして、送信側においては、基準クロック情報を含むMMTパケットは、専用のIPデータフローに格納され、あらかじめ定められた、送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、及びプロトコル種別が付与される。
このように生成された伝送路符号化データを受信した受信装置20においては、TLVデマルチプレクサ12があらかじめ定められたIPデータフロー取得することにより、基準クロック情報を含むIPパケットを抽出することができる。
なお、IPパケットがヘッダ圧縮される場合には、例えば、同一のIPデータフローであることを示すコンテクスト識別子に、基準クロック情報を含むIPパケットであることを示す識別子が付与される。コンテクスト識別子は、圧縮IPパケットヘッダに格納されている。この場合、受信装置20は、圧縮IPパケットヘッダのコンテクスト識別子を参照することにより、基準クロック情報を含むIPパケットを抽出できる。
また、基準クロック情報を含むIPパケットは、ヘッダ圧縮されないと規定されてもよいし、必ずヘッダ圧縮されると規定されてもよい。基準クロック情報を含むIPパケットには、あらかじめ定めされたコンテクスト識別子が付与され、すべてのヘッダが圧縮されると規定されてもよい。
また、TLVのデータタイプフィールドに、基準クロック情報を含むIPデータフローに属するIPパケットであることを示す識別子、または、基準クロック情報を含むIPデータフローに属する圧縮IPパケットであることを示す識別子などを定義する方法も考えられる。また、このような識別子は、TLVのデータタイプフィールド以外のフィールドに定義されてもよい。
基準クロック情報を下位のレイヤから直接参照する場合、基準クロック情報はあらかじめ定められた位置に格納され、基準クロック情報が格納されるパケット(MMTパケット、IPパケット、及びTLVパケットなど)は、基準クロック情報専用のパケットとする。また、パケットヘッダ長は固定長にするなど、基準クロック情報よりも前のフィールドの長さは一定となるようにする。
このとき、基準クロック情報よりも前のフィールドの長さは、一定でなくてもよい。下位のレイヤにおいて、基準クロック情報よりも前のフィールドの長さが特定できればよい。例えば、基準クロック情報までの長さの情報としてAとBの2種類がある場合、受信装置20は、下位レイヤにおいてAとBのどちらであるかをシグナリングすることにより、基準クロック情報の位置を特定できる。或いは、送信側で、上位レイヤの基準クロック情報を直接参照可能な基準クロック情報の位置情報を下位レイヤに格納し、受信装置20は、下位レイヤから位置情報に基づいて参照してもよい。
以下、上位レイヤの基準クロック情報を早く取得する方法について具体的に説明する。
受信装置20は、TLVのデータタイプを判定し、基準クロック情報を含むと判定されれば、IPパケットからMMTパケット内に含まれる基準クロック情報を直接取得する。
このように、受信装置20は、IPアドレスやポート番号、コンテクスト識別子を解析することなく、IPパケットや圧縮IPパケットから特定位置のビット列を抽出することで、MMTパケットに含まれる基準クロック情報を抽出してもよい。特定位置のビット列を抽出するとは、例えば、TLVパケットヘッダから、固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することを意味し、これにより、基準クロック情報が取得される。
基準クロック情報を抽出するための固定長バイトのオフセットの長さは、IPパケットと圧縮IPパケットとのそれぞれにおいて一意に決まる。このため、受信装置20は、TLVのデータタイプを判定した後、直ちに固定長バイトだけオフセットした位置から特定の長さ分の情報を抽出することにより基準クロック情報を取得できる。なお、このときの抽出は、TLVパケットヘッダから固定長オフセットした位置ではなく、TLVの特定のフィールドから固定長オフセットした位置から行われてもよい。
なお、上記の方法は一例であり、他のプロトコルや識別子を定義することにより、下位レイヤから上位レイヤの基準クロック情報が取得されてもよい。例えば、IPパケットに基準クロック情報を含むかどうかの識別子がTLVデータタイプ以外のフィールドに格納されてもよい。
また、例えば、IPアドレスやポート番号、コンテクスト識別子を解析することなく、IPパケットまたは圧縮IPパケットから特定位置のビット列を抽出することで、MMTパケットに含まれる基準時刻情報を抽出してもよい。
IPデータフローの識別情報から基準クロック情報を含むIPデータフローを判定できない場合には、基準クロック情報を含むMMTパケットに付与された固有の識別情報(パケットID)に基づいて基準クロック情報を含むMMTパケットが特定されてもよい。この場合、上述のように特定のフィールドから基準クロック情報が抽出される。
また、MMTパケットに含まれる基準クロック情報があらかじめ定められた位置に格納されていない場合、または、MMTパケットに含まれる基準クロック情報が格納されている位置を特定できない場合が想定される。このような場合、受信装置20は、上記の方法を用いて基準クロック情報を含むMMTパケットを特定し、MMTパケットヘッダ情報を基に基準クロック情報の位置を特定し、抽出する。
なお、上記では、MMTパケットがIPパケットに格納される場合を例に説明したが、IPパケットに格納されるデータは、MMTパケットでなくてもよく、例えば、他のデータ構造を持つデータでもよい。つまり、基準クロック情報は、IPパケットに、MMTパケットと異なるデータ構造で含まれてもよい。他のデータ構造を持つデータの場合でも、上記の例と同様に、基準クロック情報を含むデータが専用のIPデータフローに格納され、基準クロック情報を含むデータであることを示す識別情報や基準クロック情報を含むIPデータフローであることを示す識別情報が付与される。
受信装置20は、基準クロック情報を含むデータであることや、基準クロック情報を含むデータを含むIPデータフローであること識別し、基準クロック情報を含む場合には、基準クロック情報を抽出する。また、受信装置20は、データの特定の位置に基準クロック情報が格納されている場合は、下位のレイヤのパケット構成から特定の位置を参照することでデータに含まれる基準クロック情報を抽出できる。
上記の例では、IPパケットや圧縮IPパケットから基準クロック情報を抽出するために、受信装置20は、IPパケットであるか圧縮IPパケットであるかに基づいて、それぞれ異なる固定長オフセット位置から基準クロック情報を抽出する。しかしながら、基準クロック情報を含むIPパケットはヘッダ圧縮されない、または、基準クロック情報を含むすべてのIPパケットがヘッダ圧縮されると定められていれば、受信装置20におけるIPパケットか圧縮IPパケットかの判定を省略することができる。また、圧縮IPパケットのヘッダが復元された後に、基準クロック情報を含むかどうかの判定が行われてもよい。
以下、IPパケットまたは圧縮IPパケットから特定位置のビット列を抽出する場合の受信方法について、フローチャートを参照しながら説明する。図21は、IPパケットまたは圧縮IPパケットから特定位置のビット列を抽出する場合のフローである。なお、この場合の受信装置20の構成は、図8に示されるブロック図と同様である。
図21のフローにおいては、まず、復号部11は、受信部10が受信した伝送路符号化データを復号し(S141)、伝送路スロットからTLVパケットを抽出する(S142)。
次に、TLVデマルチプレクサ12は、TLVパケットのデータタイプを解析し(S143)、データタイプが基準クロック情報を含むIPであるかどうかの判定を行う(S144)。データタイプが基準クロック情報を含むIPパケットでないと判定された場合(S144でNo)、フローは終了する。データタイプが基準クロック情報を含むIPパケットであると判定された場合(S144でYes)、IPパケット及びMMTパケットを解析し、IPヘッダが圧縮されているかどうかの判定を行う(S145)。
IPヘッダが圧縮されていない場合(S145でNo)、基準クロック情報抽出部15は、TLVヘッダから固定長Nバイトだけオフセットした位置のMMTパケットの中に含まれる基準クロック情報を取得する(S146)。IPヘッダが圧縮されている場合(S145でYes)、基準クロック情報抽出部15は、TLVヘッダから固定長Mバイトだけオフセットした位置のMMTパケットの中に含まれる基準クロック情報を取得する(S147)。
例えば、ステップS145においてIPヘッダが圧縮されていると判定された場合、ステップS146では、基準クロック情報抽出部15は、TLVヘッダからNバイトオフセットした位置からMMTパケットに含まれる基準クロック情報を取得する。一方、ステップS145においてIPヘッダ圧縮されていないと判定された場合、ステップS147において、基準クロック情報抽出部15は、TLVヘッダからMバイトオフセットした位置からMMTパケットに含まれる基準クロック情報を取得する。
最後に、基準クロック生成部16は、基準クロック情報を基に、システムクロックを生成する(S148)。
なお、IPパケットがIPv4であるか、IPv6であるかによって、IPパケットヘッダのデータ構造が異なるため、固定長Nバイトや、Mバイトは異なる値となる。
音声、映像、及び制御信号などを含む通常のMMTパケットは、通常のステップでDEMUX処理が行なわれるのに対し、基準クロック情報を含むMMTパケットは、下位レイヤから上位レイヤまでのDEMUX処理が一括で行われる。これにより、上位レイヤに基準クロック情報が格納されている場合であっても、下位レイヤにおいて基準クロック情報の取得ができる。つまり、基準クロック情報の取得のための処理を軽減し、かつ、基準クロック情報の取得までの時間を短縮することができ、ハードウェア実装も容易となる。
(実施の形態2)
現在、高度BS伝送方式におけるTMCC制御情報(以下、単にTMCCとも記載する)の拡張領域の活用方法として、緊急性の高い情報などをペイロードとして送信する方法がARIB(電波産業会)において検討されている。
しかし、提案されている従来のTMCC制御情報の拡張領域の使用方法は、数フレームに渡るTMCC制御情報を用いて、テキストや画像などのデータペイロードを送信する方法に限定したものである。したがって、TMCC制御情報の拡張領域の使用方法が限定されてしまうという課題があった。
特に、従来の伝送モードや、スロット情報などの、フレーム毎に値の変わらない制御情報(制御信号)、または、基準クロック情報など、フレーム毎に値の変わる制御情報は、数フレームにまたがるペイロードデータと同時にTMCC制御情報の拡張領域に格納することができなかった。
そこで、実施の形態2では、TMCC制御情報の拡張領域に格納される情報やデータの種別に応じて、TMCC制御情報の拡張領域を分割することにより、受信処理が異なるデータを同時にTMCC制御情報の拡張領域に格納することを可能とする方法について説明する。このような方法で拡張領域の使用に拡張性を持たせることにより、拡張の柔軟性を向上させることができる。また、受信装置は、データの種別に基づいて、種別毎に異なる受信方法でTMCC制御情報の受信や解析をすることができる。
また、このような方法によれば、数フレームにまたがるペイロードデータと、1フレームのみのペイロードデータとを拡張領域において混在させることが可能である。数フレームにまたがるペイロードデータが受信できない間でも、1フレームのみのペイロードデータを先に取得できることから、緊急性の高い情報をより早く取得、提示することが可能となる。
[TMCC拡張情報の構成]
以下、TMCC拡張情報の構成について説明する。なお、TMCC制御情報の基本構成は、図16に示される構成であり、TMCC制御情報に格納される制御情報の種類は、次の二つに大別される。
一つは、フレームに関する制御情報であって、フレーム毎に値が変化しない制御情報である。このような制御情報の最小更新間隔はフレーム単位であり、値が変更される場合は2フレーム先行して変更後の情報が送信される。また、変更がある場合は、8bitの変更指示がインクリメントされることにより通知が行われる。このような制御情報は、具体的には、ポインタ情報及びスロット情報以外の情報が該当する。
もう一つは、フレームに関する制御情報であって、フレーム毎に値が変化する制御情報である。このような制御情報は、フレーム毎に値が変わる情報であるため、変更指示は行われない。このような制御情報は、具体的には、ポインタ情報及びスロット情報である。
TMCC拡張情報は、図22の(a)に示されるように、16ビットの拡張識別と3598ビットの拡張領域とで構成され、拡張識別にall 0以外の値を設定することで拡張領域が有効となる。図22は、TMCC拡張情報の構成を示す図である。
図22の(b)は、従来提案されている、拡張領域がペイロードとして使用される場合のビット割り当て方法の一例を示した図である。図22の(b)に示されるように、拡張領域がペイロードとして使用される場合、ページ数は16ビットで構成され、付加情報ペイロードは、伝送中のTMCC制御情報が何フレーム分にわたって伝送されるかを示す。
ページ番号は、16ビットで構成され、現在伝送中のTMCC制御情報がページ数のうちの何ページ目かを示す。付加情報種別は、8ビットで構成され、付加情報の種別を指定する。付加情報種別は、具体的には、例えば、文字(字幕)スーパー、グラフィック、音声などである。
このような構成の場合、拡張領域すべてをペイロードとして使用することになり、拡張領域を用いて、従来のTMCC制御情報のような制御情報を拡張領域に格納することができない。
[TMCC拡張領域の拡張方法]
ここでは、TMCC拡張領域に格納される情報やデータの種別に応じて、TMCC拡張領域を分割することにより、受信処理が異なるデータをTMCC拡張領域に格納することを実現する方法について説明する。
TMCC拡張領域に格納される情報やデータの種別(以下では拡張種別と呼ぶ)を、例えば下記のように分類する。
Type A:
・フレームに関する制御情報であり、フレーム毎に値が変化しない。
・最小更新間隔はフレーム単位である。値に変更がある場合は2フレーム先行して変更後の情報が送信される。
・また、変更がある場合は、8bitの変更指示のインクリメントにより変更の通知が行われる。
Type B:
・フレームに関する制御情報であり、フレーム毎に値が変化する。
・フレーム毎に値が変わる情報であり、変更指示は行われない。
Type C:
・ペイロードとして使用される(従来の拡張方式)。
・ただし、変更指示には、拡張領域でないTMCCと同じ変更指示フィールドが用いられてもよいし、拡張領域で独自に変更指示フィールドが規定されてもよい。
図23は、このように分類された拡張種別が用いられた拡張領域のデータ構造(ビット配置)の一例を示す図である。図24は、拡張種別を使用する場合のシンタックスを示す図である。
図23の例では、拡張種別として上記の3タイプのみが定義される。また、図24の(a)に示されるように、3タイプの拡張種別のそれぞれにおけるデータ長が格納された後に続いて、拡張種別毎に、データ長に示された長さの拡張データが格納される。受信装置においては、拡張種別毎に、データ長に示された長さのデータを拡張領域から抽出し、処理を行う。
例えば、受信装置は、TypeAのデータについては、変更指示があった場合のみデータを取得し、TypeAのデータに変更があった場合には、制御情報が変更されたとして、制御情報に変更に従った処理をする。
また、受信装置は、TypeBのデータについては、TypeBのデータがフレーム毎に値が変化するデータであることから、毎フレーム取得する。例えば、フレーム毎に値が変化する基準クロック情報がTMCC制御情報に格納される場合には、TypeBのデータ領域に格納される。
TypeCのデータには、従来の拡張方式のペイロード情報が含まれており、受信装置は、TypeCのデータについては、従来の拡張方式の取得に従った動作をする。
上記の例では、それぞれの拡張種別毎のデータ構成の詳細は別途規定される必要がある。別途規定される場合、図22の(b)に示されるTypeCのデータにおける付加情報種別や対象サービス指定方法と同様の識別子が、他のタイプにおいて規定されてもよい。なお、付加情報種別は、共通のテーブルを用いて定義されてもよいし、拡張識別と付加情報種別とがマージされてもよい。
また、データ長が途中で変わる可能性がある情報は、TypeAのデータと同様の種別とされてもよい。この場合、データ長の変更がある場合には、2フレーム先行して変更後の情報を送信することにより変更指示が行われてもよい。受信装置は、変更指示があった場合には、拡張種別のデータ長を参照し、データ長に変化がないかどうかを確認する。
なお、データ構造は、図23のような構造に限定されるものではない。例えば、拡張種別のデータ長があらかじめ固定である場合には、データ長は送信されなくてもよい。具体的には、図23において拡張種別がTypeAのデータ長が固定長である場合には、データ構造内に拡張種別TypeAのデータ長が配置されなくてもよい。また、拡張種別TypeAのデータ長及び拡張種別TypeBのデータ長が固定長である場合には、すべてのタイプのデータ長が配置されなくてもよい。また、データ構造内には、拡張種別のデータがあるかないかを示すフラグが設けられてもよい。
また、拡張種別を使用する場合のシンタックスは、図24の(a)に示されるシンタックスに限定されない。例えば、図24の(b)に示される例では、拡張領域数が設定され、拡張領域数毎に、拡張種別及び拡張領域長が格納される。続いて拡張領域数の拡張データが格納される。
このような構成は、将来の拡張種別の追加にも対応可能である。また、このような構成は、同じ拡張種別のデータを複数格納することが可能であるため、同じ拡張種別毎のデータの構成の詳細をあらかじめ決める必要がない。また、このような構成は、ペイロードとして(TypeCとして)使用される場合でも、映像及び音声など、ページ数の異なるデータを同じフレームに複数記述できる。
なお、図24の(b)に示される構成において、拡張領域数、拡張種別、及び拡張領域長はTypeAと同様の種別とされてもよい。つまり、これらの情報は、変更指示に従う情報であると規定されてもよい。このように、変更指示に従うデータが連続して格納されることにより変更有無の判定が容易になる。
また、将来の拡張に備え、拡張種別に未定義領域が設けられてもよい。将来的に導入される拡張種別としては、例えば、次のような種別が想定される。
・数フレーム毎に更新される制御信号であり、変更指示は行われない。
・緊急用の信号の場合、TypeAと同様に変更指示が行われるが、2フレーム先行した情報でなく、変更指示の取得後、当該フレームにおいて直ちに処理が行われる。
また、上記の緊急用の信号の場合、緊急用のフラグは、変更指示を伴う拡張種別を用いて送信され、緊急用のデータはペイロードを用いて送信されてもよい。また、拡張種別は、変更指示に従うか否かで分けられてもよい。
[詳細構成と動作フロー]
以上説明したような受信装置の機能構成と動作フローについて説明する。図25は、実施の形態2に係る受信装置の機能構成を示すブロック図である。図26は、実施の形態2に係る受信装置の動作フローを示す図である。なお、以下の説明では、拡張種別は、上述のようにTypeA、TypeB、及びTypeCの3つのみであるとする。
図25に示されるように受信装置40は、拡張識別部41と、拡張種別判定部42と、変更指示確認部43と、データ更新確認部44と、更新データ取得部45とを備える。
まず、拡張識別部41は、TMCC制御情報の拡張識別を解析する(S161)。ここで拡張識別が、all 0以外であれば、拡張領域が有効であるとして、受信装置40は、拡張領域毎に以下の処理を実行する。
次に、拡張種別判定部42は、拡張種別の判別(判定)を行う(S162)。拡張種別がTypeAであると判別された場合(S162でTypeA)、拡張領域長により特定される領域のデータは、フレーム毎に値が変化せず、変更指示に従う制御情報である。したがって、変更指示確認部43は、フレーム毎に変更指示を確認する(S163)。
続いて、データ更新確認部44は、データ更新の判定を行う(S164)。変更指示があり、かつ当該拡張データに変更があると判定された場合(S164でYes)、更新データ取得部45は、更新された拡張データを取得し、変更に伴う処理を実行する(S165)。
一方、ステップS164において上記のように判定されなかった場合(S164でNo)、更新データ取得部45は、当該拡張データに変更がないと判断する。
また、ステップS162において拡張種別がTypeBであると判別された場合(S162でTypeB)、更新データ取得部45は、拡張領域長により特定されるデータを参照し、フレーム毎に更新されるデータを取得し、変更に伴う処理を実行する(S167)。
ステップS162において拡張種別がTypeCであると判別された場合(S162でTypeC)、更新データ取得部45は、従来のペイロード拡張方式の受信方法に基づく処理を実行する(S166)。
なお、上述のように拡張領域数、拡張種別、及び拡張領域長が、変更指示に従うTypeAと同様の種別であると判別された場合には、更新データ取得部45は、変更指示を確認し、変更指示がある場合には、情報が更新されているかどうかを確認する。
なお、受信装置40は、拡張種別に基づいて受信処理を決定し、どの処理ブロックにおいてデータ処理をするかを決定してもよい。受信装置40は、例えば、TypeAのデータ及びTypeBのデータは、ハードウェアで処理し、TypeCのデータはソフトウェアで処理することを決定してもよい。
[効果等]
以上説明したように、実施の形態2では、高度BS伝送方式におけるTMCC拡張領域を拡張種別毎に分割し、拡張データをTMCC拡張領域に格納する方法について説明した。このような方法においては、受信装置40は、拡張種別に基づいて拡張データの処理方法を決定する。
これにより、受信処理が異なる複数のデータを同時にTMCC拡張領域に格納することが可能となる。つまり、TMCC拡張領域の使用方法に拡張性を持たすことが可能となる。
具体的には、例えば、ペイロード及び基準クロック情報を同時に拡張領域に格納することが可能となる。
また、数フレームにまたがるペイロードデータと、1フレームのみのペイロードデータとをTMCC拡張領域に混在させることも可能となる。したがって、受信装置40は、数フレームにまたがるペイロードデータが受信できない間でも、1フレームのみのペイロードデータを先に取得できる。よって、受信装置40は、緊急性の高い情報をより早く取得及び提示することが可能となる。
(実施の形態3)
実施の形態3では、各々が異なるレイヤに属する複数の基準クロック情報を送信する方法について説明する。
[概要]
図27は、複数レイヤのそれぞれに基準クロック情報が格納される例を模式的に示す図である。
図27の例では、第1のレイヤは第2のレイヤに対して上位のレイヤであり、第1のレイヤには、第1の基準クロック情報が格納される。第2のレイヤには、第2の基準クロック情報が格納される。
送信装置は、基本的に第1のレイヤのMUX処理の後に第2のレイヤのMUX処理をする。また、受信装置は、基本的に第2のレイヤのDEMUX処理の後に第1のレイヤのDEMUX処理をする。
第1の基準クロック情報を第1のレイヤに格納し、第2の基準クロック情報を第2のレイヤに格納する場合、送信装置は、第1の基準クロック情報と、第2の基準クロック情報との関係性を示す情報として、例えば下記に示す情報を格納することができる。
第1の例として、送信装置は、送信信号(例えば、伝送フレーム)内に複数の基準クロック情報が格納されていることを示す情報を送信信号に含めることができる。
具体的には、送信装置は、基準クロック情報が含まれるレイヤのうち、少なくとも1つ以上のレイヤにおいて、当該レイヤ以外のレイヤにも基準クロック情報が格納されていることを示す情報を格納する。
また、送信装置は、基準クロック情報が含まれないレイヤにおいて、複数の基準クロック情報が格納されていることを示してもよい。例えば、送信装置は、下位レイヤ(第2のレイヤ)において上位レイヤ(第1のレイヤ)に基準クロック情報を含むかどうかを示す情報を格納してもよい。この場合、受信装置は、下位レイヤの処理において上位レイヤに基準クロック情報を含むかどうかを考慮して、下位レイヤの基準クロック情報の取得及び基準クロックの再生を行うかどうかを判定できる。
第2の例として、送信装置は、第1の基準クロック情報及び第2の基準クロック情報に関する情報を送信信号に含めることができる。
具体的には、送信装置は、それぞれのレイヤに、当該レイヤに含まれる基準クロック情報の種類を示す情報を格納する。あるいは、送信装置は、それぞれのレイヤに、当該レイヤ以外のレイヤに含まれる基準クロック情報の種類を示す情報を格納する。
基準クロック情報には、例えば、32bitのNTP、64bitのNTP、24bitのSMPTEタイムコードなどの種類があり、基準クロック情報の種類を示す情報は、基準クロック情報のフォーマット(精度等の情報を含む)を特定できる情報である。
なお、あらかじめ所定の種類の基準クロック情報が含まれていることが既知である場合は、このような情報は含まれなくてよい。
第3の例として、送信装置は、第1の基準クロック情報と第2のクロック情報の相対関係を示す情報を送信信号に含めることができる。
具体的には、送信装置は、基準クロック情報の精度の相対関係を示す情報を含めることができる。例えば、送信装置は、第1の基準クロック情報の精度に対して第2の基準クロック情報の精度が高いまたは低いことを示す情報を含める。
また、このような相対関係を示す情報は、基準クロック情報の総ビット数の大小に基づく相対関係を示す情報であってもよいし、整数部のビット数の大小に基づいてダイナミックレンジの相対関係を示す情報であってもよい。
あるいは、相対関係を示す情報は、小数部のビット数の大小に基づいて分解能(解像度)の精度の相対関係を示す情報であってもよい。また、相対関係を示す情報は、送信装置における基準クロック情報のそもそもの信頼性や、伝送路の品質、送信処理や受信処理における処理能力の違いに起因する精度の違いに基づいて、基準クロック情報の取得時における精度の相対関係を示す情報であってもよい。
また、相対関係を示す情報は、基準クロック情報間の精度の差を示す情報であってもよい。例えば、小数ビット数に差がある場合、小数ビット数の差を示す情報であってもよい。相対関係を示す情報は、互いの精度が同じであるかを示す情報を示す情報であってもよいし、精度が異なる場合のみ相対関係を示す情報として格納されてもよい。なお、あらかじめ精度の相対関係が既知である場合は、このような精度の相対関係を示す情報は含まれなくてもよい。
このような、精度の相対関係を示す情報が送信されれば、受信装置は、送信された情報が第1の基準クロック情報の精度に対して第2の基準クロック情報の精度が低いことを示す場合、第2の基準クロック情報の取得及び再生を実施せず、第1の基準クロック情報の取得及び再生を実施し、第1の基準クロック情報に基づいて同期再生を行う、といった制御ができる。あるいは、受信装置は、送信された情報が第1の基準クロック情報の精度に対して第2の基準クロック情報の精度が高いことを示す場合、第1の基準クロック情報の取得及び再生を実施せず、第2の基準クロック情報の取得及び再生を実施し、第2の基準クロック情報に基づいて同期再生を行う、といった制御ができる。
第4の例として、送信装置は、基準クロック情報間の時間の相対関係を示す情報を送信信号に含めることができる。具体的には、送信装置は、第1の基準クロック情報と第2の基準クロック情報の相対時刻を示す情報を送信する。例えば、送信装置は、MMT方式におけるCRI_descriptorを用いて送信する。なお、第1の基準クロック情報と第2の基準クロック情報とが同じ基準クロックに基づいて生成されたものであるかどうかを示す情報が含まれてもよい。
それぞれの基準クロック情報が、同じ基準クロックに基づいて生成される場合、受信装置においては、通常、第1の基準クロック情報と第2の基準クロック情報の取得のタイミングに差がある。つまり、それぞれの基準クロック情報のEnd−to−End遅延に固定の時間差が生じる。
このため、送信装置は、第1の基準クロック情報の付与タイミングと第2の基準クロック情報の付与タイミングとの時間差Δ_Aを算出し、算出した時間差Δ_Aを、第1の基準クロック情報と第2の基準クロック情報の取得のタイミングに相当する時間として送信信号に格納する。受信装置は、時間差Δ_Aを送信信号から取得し、時間差Δ_Aに基づいて第1の基準クロック情報と第2の基準クロック情報とのEnd−to−End遅延差を補正する。
また、それぞれの基準クロック情報が同じフォーマットの基準クロックに基づいて生成されており、それぞれの基準クロック情報に固定の遅延差Δ_Bがある場合、送信装置は、基準クロック情報の固定の遅延差Δ_Bを示す情報を格納し、送信する。受信装置は、遅延差Δ_Bを取得し、遅延差Δ_Bに基づいて基準クロックの固定遅延差を補正する。
また、それぞれの基準クロック情報の基になる基準クロックに固定遅延Δ_Bがある場合、送信装置は、下位のレイヤである第2のレイヤに固定遅延Δ_Bを含めて送信する。
また、それぞれの基準クロック情報、同じフォーマットの基準クロックに基づいて生成されている場合、第2の基準クロック情報は、第1の基準クロック情報をベースとして、第1のクロック情報に対する差分で表されてもよい。この場合。第2の基準クロック情報がベースとされてもよい。
第5の例として、送信装置は、複数の基準クロック情報が格納されている場合、異なるレイヤに格納されている基準クロック情報を用いるかどうかの情報を送信信号に含めることができる。送信装置は、例えば、第2のレイヤに格納された第2の基準クロック情報を第1のレイヤにおいて使用することを指示する情報を送信信号に含める。この場合、受信装置は、当該情報に基づいて、第2の基準クロック情報を生成し第1のレイヤに出力することを決定することができる。
以上説明したような情報は、少なくとも1つ以上のレイヤに格納される。例えば、このような情報は、第1のレイヤのみに上記情報が格納されてもよいし、第2のレイヤのみに格納されてもよい。また、このような情報は、両方のレイヤに格納されてもよい。あるいは、それぞれのレイヤにおいて、当該レイヤにおける基準クロック情報に関する情報が格納され、相対関係を示す情報のみが少なくとも1つ以上のレイヤに格納されてもよい。
なお、相対関係を示す情報は、下位のレイヤ(第2のレイヤ)に格納されることが望ましい。あるいは、第2のレイヤよりも下位のレイヤ(図27で図示せず)に格納されてもよい。受信装置では、下位のレイヤ(第2のレイヤ)のDEMUX処理の際に、上位のレイヤ(第1のレイヤ)の基準クロック情報に関する情報を取得できることにより、より高速な処理が可能となる。
なお、第1のレイヤと第2のレイヤとの組み合わせは、どのような組み合わせであってもよい。例えば、第1のレイヤと第2のレイヤとの組み合わせは、MMTレイヤとIPレイヤ、MMTレイヤと伝送レイヤ、IPレイヤと伝送レイヤ、のそれぞれの組み合わせであってもよい。また、第1のレイヤと第2のレイヤとの組み合わせは、MMToverTSの場合は、MMTとTSとの組み合わせでもよい。
また、上記のような情報は、各レイヤの制御信号に格納される。例えば、MMT方式では、ディスクリプタやテーブル、メッセージ、パケットヘッダ情報に格納され、MPEG2−TS方式では、ディスクリプタやテーブル、セクション、ヘッダ情報に格納される。また、伝送レイヤにおけるTMCCやスロットヘッダに格納されてもよい。伝送方式がDVBである場合は、TPS、L1データ、L2データ、P1データ、P2データなどに格納される。
なお、第1の基準クロック情報と第2の基準クロック情報とは、同じ種類の基準クロック情報であってもよいし、異なる種類の基準クロック情報であってもよい。また、第1の基準クロック情報と第2の基準クロック情報とは、精度の異なる基準クロック情報であってもよい。第1の基準クロック情報と第2の基準クロック情報とは、同じ基準クロックに基づいた基準クロック情報であってもよいし、それぞれ異なる基準クロックに基づいた基準クロック情報であってもよい。
また、送信装置は、3以上の基準クロック情報を送信してもよいし、3以上のレイヤにそれぞれ基準クロック情報を格納して送信してもよい。また、同じレイヤ内のデータ構造の中で異なるフィールドのそれぞれに基準クロック情報が格納されてもよい。第1のレイヤと第2のレイヤとの間には、他のレイヤが存在していてもよい。
基準クロック情報は、例えば、NTP、タイムコード、及び、PTPであるが、これ以外の基準クロック情報であってもよい。また、基準クロック情報は、他の時刻に関する情報(例えば、TOT(Time Offset Table)及びTDT(Time Date Table))でもよい。
図28は、一つのレイヤに複数の基準クロック情報が格納される例を模式的に示す図である。図28の例では、第1のレイヤには、第1の基準クロック情報、第2の基準クロック情報、及び第3の基準クロック情報の3つの基準クロック情報が含まれる。
この場合も、送信装置は、第1の基準クロック情報及び第2の基準クロック情報に関する情報や、それぞれの(精度や時刻の)相対関係を示す情報などを格納することができる。
一例として、TMCCに複数の基準クロック情報を格納する場合の例について説明する。図17で説明したように、高度BS伝送方式では16本のストリームを送信することができ、例えば、異なる放送局のデータがストリームに分けて格納されることが想定される。図29は、異なる放送局のデータがストリームに分けて格納される例を説明するためのブロック図である。
図29に示されるように、第1の放送局51、第2の放送局52、及び第3の放送局53は、それぞれの放送局において生成したデータを、それぞれ光回線などの有線や無線を用いて衛星の送信局54に送信する。衛星の送信局54は、それぞれの放送局のストリームを同一の高度BS伝送方式の伝送チャネルに多重する。衛星の送信局54は、それぞれの放送局のストリームに対応する基準クロック情報をTMCCに格納し、受信装置50に伝送する。
この場合、図28の例では、第1の基準のクロック情報が第1の放送局51の基準クロック情報、第2の基準クロック情報が第2の放送局52の基準クロック情報、第3の基準クロック情報は第3の放送局53にそれぞれ相当する。
ところで、それぞれの放送局が、NTPなどの共通の基準クロック情報に基づいて処理を行っている場合において、衛星の送信局54におけるそれぞれの基準クロック情報は、衛星の送信局に到着するまでの受信処理遅延や伝送遅延によるEnd−to−End遅延の違いにより時間差を有する。
ここで、それぞれの放送局において用いられる共通の基準クロック情報をNTP_baseとすると、衛星の送信局における第1の基準クロック情報はNTP_base+Δ1、第2の基準クロック情報はNTP_base+Δ2、第3の基準クロック情報はNTP_base+Δ3と表される。
この場合、図30に示されるように、送信装置は、共通となる基準クロック情報NTP_baseを送信し、かつ、それぞれの基準クロック情報と共通の基準クロック情報との差分情報(Δ1、Δ2、Δ3)を送信してもよい。図30は、差分情報の送信方法を説明するための図である。また、例えば、64bitの基準クロック情報のうち、ベースの基準クロック情報は上位16bitによって表現し、差分情報は残りの48bitによって表現することにより、基準クロック情報の伝送時の情報量(サイズ)を削減することができる。
なお、ベースとなる基準クロック情報は、NTP_baseでなくてもよく、複数の基準クロック情報の中で、最も早い(遅延の少ない)基準クロック情報であってもよい。あるいは、ベースとなる基準クロック情報(基準値)は、最も早い基準クロック情報の値よりも小さな値であればよい。
また、図31に示されるように、ベースの基準クロック情報は、毎フレーム送信され、差分情報は、3フレーム毎に順番に送信されるなど、ベースの基準クロック情報と差分情報とは異なる頻度で送信されてもよい。図31は、差分情報の送信方法の変形例を説明するための図である。図31に示されるような送信方法により、基準クロック情報の伝送時の情報量(サイズ)を削減することができる。
受信装置50は、ベースの基準クロック情報を用いてベースの基準クロックを再生する。ベースの基準クロック情報の再生後に、差分情報を用いて、それぞれの基準クロックを生成してもよい。
[詳細構成と動作フロー]
ここで、受信装置50の機能構成と動作フローについて説明する。図32は、受信装置50の機能構成を示すブロック図である。図33は、受信装置50の動作フローを示す図である。なお、以下では、IPレイヤ、及び伝送レイヤのいずれか一方にのみ基準クロック情報が格納されており、いずれかの基準クロック情報に基づいて受信装置50が基準クロックを再生する例について説明される。
受信装置50は、受信部10と、復号部11と、TLVデマルチプレクサ12と、IPデマルチプレクサ13と、MMTデマルチプレクサ14と、同期部17と、復号提示部18とを備える。また、受信装置50は、第1基準クロック情報抽出部15aと、第2基準クロック情報抽出部15bと、第1基準クロック生成部16aと、第2基準クロック生成部16bとを備える。
伝送レイヤの制御情報(スロットヘッダ及びTMCCなど。ここではTMCC。)には、IPレイヤに基準クロック情報があるかどうかを示すフラグが格納される。また、伝送レイヤの制御情報には、IPレイヤに基準クロック情報がない場合に基準クロック情報が格納される。
また、伝送レイヤの制御情報には、IPレイヤに基準クロック情報がない場合に、伝送レイヤにおいて取得された基準クロック情報が上位レイヤの処理に必要かどうかを示すフラグ、または、再生された基準クロック情報が上位レイヤの処理に必要がどうかを示すフラグが格納される。
例えば、基準クロック情報が64ビットのNTPである場合、基準クロック情報を示す64ビットのフィールドにNTPが格納される。また、IPレイヤに基準クロック情報があるかどうかを示すフラグが基準クロック情報のフィールドに設けられてもよい。IPレイヤに基準クロック情報が格納されている場合は、伝送レイヤには基準クロック情報が格納される必要がないため、当該フィールドを活用できる。
例えば、IPレイヤに基準クロック情報がある場合には基準クロック情報のフィールドに所定の値(例えば、ALL1)がある場合、受信装置50は、当該値は基準クロック情報でなく、IPレイヤに基準クロック情報があることを示すフラグであると判定する。あるいは受信装置50は、基準クロック情報のフィールドにALL1が1回だけ示された場合には基準クロック情報があると判定し、ALL1が所定の回数以上連続して示された場合にはIPレイヤに基準クロック情報があると判定するなど、所定の規則に基づいた値がフラグとして用いられてもよい。
受信装置50の復号部11は、伝送レイヤにおいて制御情報であるTMCCを解析し、各種フラグや、基準クロック情報を解析する(S171)。そして、復号部11は、上記フラグに基づく判定を行う(S172)。IPレイヤに基準クロック情報がない(伝送レイヤに基準クロック情報がある)と判定された場合(S172でNo)、第2基準クロック情報抽出部15bは、伝送レイヤにおいて基準クロック情報を取得(抽出)し、第2基準クロック生成部16bは、基準クロックを再生(生成)する。
次に、復号部11は、伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要かどうかの判定を行う(S174)。伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要であると判定された場合(S174でYes)、第2基準クロック生成部16bは、ステップS174において再生した基準クロックを上位レイヤに出力する(S175)。伝送レイヤにおいて再生された基準クロックが上位レイヤの処理に必要であると判定されなかった場合(S174でNo)、処理は終了される。
一方、IPレイヤに基準クロック情報がある(伝送レイヤに基準クロック情報がない)と判定された場合(S172でYes)、伝送レイヤでは基準クロック情報の取得及び基準クロックの再生は実施されない。この場合、第1基準クロック情報抽出部15a、及び、第1基準クロック生成部16aによって、IPレイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される(S176)。
なお、伝送レイヤにおいて基準クロックの再生が必要でない場合、及び、上位レイヤが基準クロックを必要としていない場合、伝送レイヤにおける基準クロック情報の取得及び基準クロックの再生(S173)は行われなくてもよい。
また、上位レイヤにおいて基準クロックが必要な場合、再生した基準クロックを出力するのではなく、基準クロック情報を上位レイヤに渡し、上位レイヤにおいて基準クロックの再生が行われてもよい。また、伝送レイヤにおいて再生された基準クロックに基づいて、新規に基準クロック情報が生成され、生成された基準クロック情報が上位レイヤに出力されてもよい。
上位レイヤに基準クロックを出力する方法としては、再生された基準クロックをそのまま出力する方法や、取得した基準クロック情報あるいは新規に生成した基準クロック情報を、上位レイヤへ出力するデータ構造に格納あるいは変換して出力する方法などがある。
[動作フローの別の例]
次に、受信装置50の別の動作フローについて説明する。図34は、受信装置50の別の動作フローを示す図である。なお、受信装置50の構成は、図32と同様の構成である。
図34の例では、IPレイヤ、及び伝送レイヤのそれぞれに基準クロック情報が格納でき、複数の基準クロック情報が格納されている場合には、その基準クロック情報の精度の相対情報が格納されているものとする。
復号部11は、TMCCを解析し(S181)、フラグに基づく判定を行う(S182)。IPレイヤに基準クロック情報がないと判定された場合(S182でNo)、伝送レイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される(S185)。
一方、ステップS182においてIPレイヤに基準クロック情報があると判定された場合(S182でYes)、復号部11は、伝送レイヤの基準クロック情報とIPレイヤの基準クロック情報とのどちらの精度が高いかを判定する(S183)。伝送レイヤの基準クロック情報よりもIPレイヤの基準クロック情報のほうが精度が高いと判定された場合(S183でYes)、IPレイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される(S184)。伝送レイヤの基準クロック情報よりもIPレイヤの基準クロック情報のほうが精度が低いと判定された場合(S183でNo)、伝送レイヤにおいて基準クロック情報の取得及び基準クロックの再生が実施される(S185)。
[効果等]
以上説明したように、1つ以上のレイヤで複数の基準クロック情報が送信されてもよい。複数の基準クロック情報が送信されている場合、受信装置50は、どちらか一方の基準クロック情報を選択して基準クロック(システムクロック)の生成に用いてもよいし、両方を用いて基準クロックを生成してもよい。このとき、受信装置50は、精度の高い基準クロック情報を選択してもよいし、より早く取得できる基準クロック情報を選択してもよい。
また、複数のレイヤで基準クロック情報が送信されている場合、送信側では、複数のレイヤで基準クロック情報が送信されていることを示す情報が格納されてもよい。また、複数のレイヤで基準クロック情報が送信されていることを示す情報、または、基準クロック情報が送信されているレイヤやプロトコルに係る情報が、下位のレイヤにおいて送信されてもよい。さらに、異なるレイヤに格納された基準クロック情報間の関係性を示す情報が送信されてもよい。
これにより、受信装置50は、下位のレイヤのDEMUX処理時に、上位のレイヤに基準クロック情報が含まれていることを判定することができ、判定に基づいてどの基準クロック情報を用いるかを決定することができる。どの基準クロック情報を用いるかの決定は、受信装置50がどのレイヤの基準クロック再生に対応しているかどうかに基づいて決定されてもよいし、推奨される基準クロック再生が放送局によって指定されてもよい。
複数のレイヤで基準クロック情報が送信されている場合、受信装置50は、下位のレイヤにおいて基準クロック情報を抽出すると同時に、下位のレイヤから上位のレイヤに含まれる基準クロック情報を抽出してもよい。そして、受信装置50は、抽出した少なくとも1つ以上の基準クロック情報を用いて基準クロックを生成してもよい。
なお、複数の伝送路を通じて複数の基準クロック情報が送信されてもよい。この場合、複数の基準クロック情報が複数の伝送路を通じて送信されていることや、基準クロック情報が伝送されている伝送路に係る情報が送信されてもよい。
(その他の実施の形態)
以上、実施の形態について説明したが、本発明は、上記実施の形態に限定されるものではない。
例えば、従来のMMTパケットヘッダに含まれる32bitショートフォーマットNTPに加えて、より高精度な基準クロック情報を送信することが想定される。このような場合、送信側からは、受信装置が高精度な基準クロック情報を用いて32bitショートフォーマットNTPを再生するための情報がさらに送信される。このような情報は、例えば、互いのクロックの相対関係を示す時刻情報であり、CRI_descriptor()等を用いて送信される構成などが考えられる。
なお、受信装置において32bitショートフォーマットNTPが再生できる場合には、従来のMMTパケットヘッダに含まれるNTPフィールドは不要である。このため、NTPフィールドには別の情報が格納されてもよいし、NTPフィールドを削減することによりヘッダ圧縮が行われてもよい。ヘッダ圧縮がされる場合には、NTPフィールドを削減したことを示す情報が送信される。受信装置は、NTPフィールドが削減されている場合には、他の基準クロック情報を用いて基準クロックを生成するとともに、32bitショートフォーマットNTPを再生する。
また、MMTパケットが通信伝送路を用いて伝送される場合、受信装置は、QoS制御のために32bitショートフォーマットNTPを使用し、基準クロック情報は使用しない可能性がある。そのため、通信伝送路では基準クロック情報が送信されなくてもよい。また、通信伝送路のEnd−to−End遅延が一定以内である場合は、基準クロック情報をクロック再生に用いてもよい。
なお、上記実施の形態1では、MMT/IP/TLV方式を用いる場合を例に説明したが、多重化方式として、MMT方式以外の方式が用いられてもよい。例えば、MPEG2−TS方式、RTP方式、またはMPEG−DASH方式にも本発明を適用することができる。
また、IPパケットのヘッダ圧縮の方法としては、RoHC(Robust Header Compression)、及びHCfB(Header Compression for Broadcasting)がある。
IPパケットを放送に格納する方式としては、TLV方式以外にも、GSE(Generic Stream Encapsulation)方式、及びULE(Unidirectional Light−weight. Encapsulation)を用いたIPoverTS方式などがある。
以上のようないずれの方式を用いる場合にも本発明は適用可能であり、本発明の適用により、受信装置における基準クロック情報を取得までの時間の短縮や処理の軽減、ハードウェア化実装によるクロックの高精度化などを実現することができる。
なお、上記実施の形態における基準クロック情報は、多重化方式がMMTである場合は、NTPであるが、例えば、多重化方式がMPEG2−TS方式である場合には、PCR(Program Clock Reference)である。また、多重化方式がMMTである場合においても、IEEE1588で規定されるPTPをNTP形式で伝送することもある。NTPの一部のビットのみが伝送されることもある。つまり、基準クロック情報は、送信側が設定する時刻を示す情報であればよい。なお、NTPは、必ずしもインターネットで一般的に使用される、NTPサーバにおけるNTP値を意味するわけではない。
また、本発明は、上記のような方法で基準クロック情報を格納した伝送スロットを送信する送信装置(送信方法)として実現されてもよい。以下、このような送信装置の構成について補足する。図35は、送信装置の機能構成を示すブロック図である。図36は、送信装置の動作フローである。
図35に示されるように、送信装置30は、生成部31と、送信部32とを備える。なお、送信装置30の構成要素は、具体的には、マイクロコンピュータ、プロセッサ、または専用回路などによって実現される。
送信装置30は、具体的には、放送サーバであり、上記実施の形態1の「送信側」の一例である。
生成部31は、例えば、IPパケットが格納されたTLVパケットが1以上格納されたスロットを複数格納した伝送スロットを生成する(図36のS151)。
このとき、生成部31は、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケット格納されたIPパケット(以下、対象IPパケットとも記載する)に、コンテンツ(例えば、映像または音声などの放送コンテンツ)の再生のための時刻を示すNTPなどの第1の基準クロック情報を含める。このとき、対象IPパケットは、ヘッダ圧縮されていないIPパケットであり、第1の基準クロック情報は、例えば、対象IPパケット内でMMTパケットと異なるデータ構造で格納される。
また、生成部31は、伝送スロット内の制御情報(TMCC)にコンテンツの再生のための時刻を示す第2の基準クロック情報を格納する。
生成部31は、具体的には、放送コンテンツを符号化する符号化部、MMTマルチプレクサ、IPマルチプレクサ、及び、TLVマルチプレクサなどからなる。なお、TLVパケットは、第1の伝送単位の一例であり、スロットは、第2の伝送単位の一例であり、伝送スロットは、伝送用のフレームの一例である。
送信部32は、生成部31によって生成された伝送スロット(伝送スロットを含む伝送路符号化データ)を、放送を通じて送信する(図36のS152)。
上記実施の形態でも説明したように、このような送信装置30によれば、受信装置が基準クロック情報を取得する処理を簡素化できる。したがって、受信装置が基準クロック情報を取得するまでの時間を短縮することができる。
また、フレーム内の制御情報にコンテンツの再生のための時刻を示す第2の基準クロック情報が格納されることにより、受信装置は、第1の基準クロック情報及び第2の基準クロック情報のいずれの基準クロック情報を使用するかを選択できる。
(実施の形態4)
本実施の形態では、受信装置において、上位レイヤに基準クロック情報を渡す方法及びそのインターフェースについて説明する。
図37は、本実施の形態に係る受信装置60の構成を示すブロック図である。この受信装置60は、下位レイヤの処理を行う復号装置61と、上位レイヤの処理を行う逆多重化装置62とを含む。例えば、復号装置61と逆多重化装置62とは異なるLSIとして形成される。なお、復号装置61と逆多重化装置62とは単一のLSIとして形成されてもよい。
復号装置61は、受信部10と復号部11とを備える。受信部10は、伝送路符号化データを受信する。復号部11は、受信部10によって受信された伝送路符号化データを復号することでTLVパケットを抽出し、当該TLVパケットを逆多重化装置62に出力する。
逆多重化装置62は、取得部63と逆多重化部64とを備える。取得部63は、復号装置61から主力されたTLVパケットを取得する。逆多重化部64は、TLVパケットを逆多重化する。例えば、逆多重化部64は、図32に示す処理部のうち受信部10及び復号部11以外の処理部を含む。なお、逆多重化部64は、他の実施の形態で説明した受信装置に含まれる処理部のうち受信部10及び復号部11以外の処理部を含んでもよい。また、逆多重化部64は、これらの処理部の全てを含む必要はなく一部のみを含んでもよい。また、逆多重化装置62は、復号装置61の出力を制御する。
図32及び図33で説明したように、下位レイヤの復号装置61は、下位レイヤに基準クロック情報が含まれる場合に、再生した基準クロックを上位レイヤの逆多重化装置62に出力せずに、基準クロック情報を逆多重化装置62に渡し、逆多重化装置62において基準クロックを再生する方法について捕捉し、詳細を説明する。
以下では、非特許文献2(ARIB標準規格 ARIB STD−B44(2.0版)、「高度広帯域衛星デジタル放送の伝送方式」における第3章「時刻情報の伝送に関するガイドライン」)に記載される方法、及びデータ構造に基づいた基準クロックの送受信について説明する。
上記規格では、基準クロック情報をTMCCに格納する方法が示されているものの、具体的に送信される時刻情報、および受信装置における動作が規定されておらず、受信装置において正確な時刻情報を得ることができない。例えば、上記規格では「TMCCに格納する基準クロック情報は、本TMCC信号が送信サーバを出発する時刻」としているが、具体的な定義ではない。
TMCC制御情報(TMCC制御信号)は、送信装置において、伝送フレーム毎に、本線系の主信号とは別系統で生成され、誤り訂正符号化及びインターリーブ処理が行われた後に、1フレーム分の主信号(主信号も誤り訂正符号化及びインターリーブ処理を行った後の信号である。)の中に分散的にマッピングされる。
図38は、主信号及び基準クロック情報のタイミングを示す図である。
TMCC制御情報に基準クロック情報が格納される場合は、基準クロック情報(図38ではNPTn,NPTn+1,…)は、伝送フレーム時間長の間隔(T)で生成される。基準クロック情報は、生成された後、伝送フレームの単位で送出される。このとき、基準クロック情報の生成から伝送フレームの送出までには、誤り訂正符号化、インターリーブ処理、及び伝送フレーム送出タイミングなどによる処理遅延が発生する。図38では、NTPnは伝送フレームM+1に格納されて伝送され、NTPn+1は伝送フレームM+2に格納されて伝送される。なお、ここでは、伝送遅延は0として、伝送フレームの送出時刻及び受信時刻は同一であるとして説明する。
受信装置は、1伝送フレーム分のデータを受信し、誤り訂正処理及びデインターリーブ処理後にTMCC制御情報を抽出する。そのため基準クロック情報の受信タイミングは、1フレーム以上遅延する。
同様に、本線系の主信号に対しても、誤り訂正及びインターリーブ処理により送受信において処理遅延が発生する。
しかしながら、本線系と、TMCC制御情報の系とでは、送受信それぞれにおいて、遅延時間が異なるため、受信装置において取得した基準クロック情報の時刻が、本線系の時刻に対してどの時刻であるかが不明確であるという課題がある。また、受信装置において取得した基準クロック情報を上位レイヤに格納するタイミングの規定がないという課題がある。
そこで、本実施の形態では、下記方法に従い、TMCC制御情報に基準クロック情報を格納する。
送信装置は、TMCC制御情報に格納する基準クロック情報を、例えば、主信号の伝送フレームがサーバを送出する時刻(例えば、伝送フレームの先頭のパケットがサーバを送出する時刻)に設定する。
受信装置は、TMCC制御情報から抽出した基準クロック情報を、次の伝送フレームの先頭位置に格納して上位レイヤに伝送する。
上記の動作により、本線系と、TMCC制御情報の系との処理遅延の違いによる、相対的な関係は、伝送フレームの整数倍(N×T)(Nは整数)となる。
さらに、本線系とTMCC制御情報から抽出した基準クロック情報との時間関係を一致させるために、N×Tの補正がされる。
予めNを一意に決定できる場合は、送信装置がN×TFの補正をした時刻をTMCC制御情報に格納してもよいし、受信装置が時刻を補正してもよい。Nが一意に決定できない場合には、受信装置がNを推定し、時刻を補正する。
また、基準クロック情報が、TMCC制御情報に加え、主信号(TLVパケット)で伝送されている場合には、送信装置は、TMCC制御情報に、TLVパケットに格納される時刻と同一の時刻を格納する。或いは、送信装置は、TLVパケットに格納される時刻に対して、N×Tに応じた補正を行った時刻をTMCC制御情報に格納する。
受信装置では、TMCC制御情報より抽出した時刻情報にN×Tの補正を加えることにより、主信号に格納される時刻と同一の時刻を算出し、算出した時刻を上位レイヤに出力する。
なお、基準クロック情報をTMCC制御情報より抽出し、補正後の基準クロック情報を上位レイヤに伝送する方法として、受信装置は、TLVパケット内の基準クロック情報を置き換えて出力してもよい。
また、TMCC制御情報とTLVパケットとに格納される基準クロック情報において基準となる時刻は同一であるため、上位レイヤではこれらの基準クロック情報を同じ情報として扱うことが可能である。
また、受信装置60は、TMCC制御情報とTLVパケットとに格納される基準クロック情報のどちらか一方のみを主信号(TLVパケット)として出力する方法と、両方を出力する方法となどを、選択スイッチ等により切り替えてもよい。また、下位レイヤにおけるこの切り替えは、上位レイヤの逆多重化装置62が選択してもよい。また、復号装置61と逆多重化装置62とが物理的に異なる場合は、レジスタなどにより一方の方法が選択されてもよい。また、TMCC制御情報とTLVパケットとに格納される基準クロック情報のどちらか一方のみを出力する場合は、どちらを出力するかが選択できてもよい。
ここで、基準クロック情報が主信号(TLVパケット)で伝送される場合は、基準クロック情報は、伝送フレームにおけるTLVストリームの先頭スロットの先頭TLVパケットに格納されている。よって、復号装置61は、伝送レイヤにおいて、基準クロック情報が格納されているTLVパケットを一意に特定できる。
しかし、上位レイヤの逆多重化装置62では、伝送フレームの境界情報を把握できないため、受信したTLVパケットが基準クロック情報を含むかどうかを判定できるのが、TLVパケットヘッダ及びIPパケットヘッダの解析後となる。そこで、本実施の形態では、下位レイヤの復号装置61が上位レイヤの逆多重化装置62に対し、そのTLVパケットが伝送フレームにおけるTLVストリームの先頭であること、又は、そのTLVパケットが基準クロック情報を含むことをシグナリング(通知)する。これにより、上位レイヤの逆多重化装置62は、そのTLVパケットが基準クロック情報を含むことを、IPパケットをヘッダを解析することなしに、検出することができる。
TLVパケットが伝送フレームにおけるTLVストリームの先頭であること、又は、TLVパケットが基準クロック情報を含むことをシグナリングする方法としては、例えば、TLVパケットのパケットタイプの未定義領域を活用する方法がある。
例えば、IPv4パケットに基準クロック情報が含まれている場合は、復号装置61は、TLVタイプを、IPv4パケットを示すTLVタイプから、基準クロック情報が含まれるIPv4パケットであることを示すTLVタイプに書き換え、書き換え後のTLVパケットを逆多重化装置62に出力する。また、IPv6パケットに基準クロック情報が含まれている場合は、復号装置61は、TLVタイプを、IPv6パケットを示すTLVタイプから、基準クロック情報が含まれるIPv6パケットであることを示すTLVタイプに書き換え、書き換え後のTLVパケットを逆多重化装置62に出力する。
また、受信装置60は、復号装置61から逆多重化装置62に、TLVパケットが基準クロック情報を含むことをシグナリングするかどうかを選択できるスイッチなどを有してもよい。例えば、この選択は逆多重化装置62から行われてもよい。
以上の処理により、高精度な基準クロック情報の取得、及びクロック再生が可能となる。
図39は、受信装置60の復号部11における動作フローを示す図である。
まず、復号部11は、伝送フレームを復号し(S191)、その後、処理をする対象の基準クロック情報が、TMCCに格納される基準クロック情報であるか、主信号に格納される基準クロック情報であるかを判定する(S192)。復号部11は、主信号に格納される基準クロック情報を処理する場合(S192で主信号)には、TLVパケットをそのまま上位レイヤに出力する(S193)。一方、復号部11は、TMCC制御情報に格納される基準クロック情報を処理する場合(S192でTMCC)には、TMCC制御情報から基準クロック情報を抽出し、抽出した基準クロック情報を補正し、補正後の基準クロック情報を、伝送フレームにおけるTLVストリームの先頭TLVパケットに格納し、当該TLVパケットを逆多重化装置62に出力する(S194)。
図40は、復号部11を含む受信装置60における動作フローを示す図である。
まず、逆多重化装置62(上位レイヤ)は、復号装置61から逆多重化装置62へ出力する基準クロック情報を指定する(S201)。逆多重化装置62に出力する基準クロック情報が主信号に含まれる基準クロック情報である場合(S202で主信号)、復号装置61は、TLVパケットをそのまま逆多重化装置62に出力する(S203)。一方、逆多重化装置62に出力する基準クロック情報がTMCC制御情報に格納される基準クロック情報である場合(S202でTMCC)、復号装置61は、TMCC制御情報から基準クロック情報を抽出し、抽出した基準クロック情報を補正し、補正後の基準クロック情報を、伝送フレームにおけるTLVストリームの先頭TLVパケットに格納し、当該TLVパケットを逆多重化装置62に出力する(S204)。
図41は、復号装置61が、そのTLVパケットが基準クロック情報を含むかどうかをTLVパケットタイプにシグナリングしている場合の、逆多重化装置62における動作フローを示す図である。
まず、逆多重化装置62は、復号装置61から取得したTLVパケットのパケットタイプを解析し(S211)、当該TLVパケットが基準クロック情報を含むかどうかを判定する(S212)。
当該TLVパケットが基準クロック情報を含む場合(S212でYes)には、逆多重化装置62は、IPパケットヘッダを解析せずに、基準クロック情報を取得する(S213)。これにより、処理時間の短縮、及び処理量の削減が可能である。
一方、当該TLVパケットが基準クロック情報を含まない場合(S212でNo)には、逆多重化装置62は、当該TLVパケットに基準クロック情報が含まれないとして通常のTLVDemux及びIPDemuxを行う(S214)。
なお、放送サービスのIPデータフローが、MMTパケットを格納するIPデータフローと基準クロック情報を格納するIPデータフローの2つである場合、受信装置60が、TLVパケットタイプにより基準クロック情報を識別することにより、IPアドレスの解析が不要になる。なぜならば、基準クロック情報をTLVパケットタイプにより識別することにより、基準クロック情報を格納するIPデータフローおよびMMTパケットを格納するIPデータフローはそれぞれ1つであることから、MMTパケットを格納するIPデータフローを識別するためのIPアドレスの解析も不要となるためである。
以上のように、本実施の形態に係る復号装置61及び逆多重化装置62には以下の処理を行う。
図42は、本実施の形態に係る復号装置61における動作フローを示す図である。
まず、受信部10は伝送スロットを受信する(S221)。また、伝送スロットとは、図13に示すように、コンテンツが多重化されることで得られたTLVパケット(第1の伝送単位)が1以上含まれるスロット(第2の伝送単位)を複数格納した伝送用のフレームである。また、上述したように、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットは基準クロック情報を含む。
次に、復号部11は、伝送スロットを復号することで複数のTLVパケットを取得する。また、復号部11は、さらに、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットを特定するための情報を生成する(S222)。
具体的には、復号部11は、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットに格納される、当該TLVパケットの管理情報(パケットタイプ)として、当該TLVパケットが基準クロック情報を含むことを示す情報を格納する。または、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットを特定するための情報は、伝送スロット内の複数のTLVパケットのうち、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットを示す情報である。
つまり、復号部11は、伝送スロット内の先頭のスロット内で先頭に位置するTLVパケットを特定するための情報を生成し、当該情報を逆多重化装置62に通知する。具体的には、復号部11は、TLVパケット内に当該情報を追加する、又は、他の信号により当該情報を逆多重化装置62に通知する。
次に、復号部11は、上記情報を含むTLVパケット、又は、TLVパケット及び上記情報を逆多重化装置に出力する(S223)。
図43は、本実施の形態に係る逆多重化装置62における動作フローを示す図である。
まず、取得部63は、復号装置61から伝送スロットを取得する(S231)。ここで、TLVパケットの各々は、当該TLVパケットが基準クロック情報を含む場合には、当該当該TLVパケットが基準クロック情報を含むことを示す管理情報(パケットタイプ)を含む。
逆多重化部64は、管理情報に基づき、基準クロック情報を含むTLVパケットを特定し(S232)、特定したTLVパケットから基準クロック情報を取得する(S233)。また、逆多重化部64は、複数のTLVパケットを逆多重化することでコンテンツを取得する(S234)。
以上により、本実施の形態に係る受信装置60では、復号装置61から逆多重化装置62に、基準クロック情報を含むTLVパケットを特定するための情報が通知される。これにより、逆多重化装置62は、IPパケットヘッダ等を解析することなく、基準クロック情報を取得できるので、処理量の低減及び高速化を実現できる。
なお、上記実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
また、各構成要素は、回路でもよい。これらの回路は、全体として1つの回路を構成してもよいし、それぞれ別々の回路でもよい。また、これらの回路は、それぞれ、汎用的な回路でもよいし、専用の回路でもよい。
例えば、上記各実施の形態において、特定の処理部が実行する処理を別の処理部が実行してもよい。また、複数の処理の順序が変更されてもよいし、複数の処理が並行して実行されてもよい。
以上、一つまたは複数の態様に係る受信装置(受信方法)及び送信装置(送信方法)について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、一つまたは複数の態様の範囲内に含まれてもよい。
本発明の送信方法は、MMT方式を放送システムに適用する場合に、受信側で基準クロック情報を取得するための処理を軽減することができる送信方法として有用である。
10 受信部
11 復号部
12 TLVデマルチプレクサ
13 IPデマルチプレクサ
14 MMTデマルチプレクサ
15 基準クロック情報抽出部
15a 第1基準クロック情報抽出部
15b 第2基準クロック情報抽出部
16 基準クロック生成部
16a 第1基準クロック生成部
16b 第2基準クロック生成部
17 同期部
18 復号提示部
20、40、50、60 受信装置
30 送信装置
31 生成部
32 送信部
41 拡張識別部
42 拡張種別判定部
43 変更指示確認部
44 データ更新確認部
45 更新データ取得部
51 第1の放送局
52 第2の放送局
53 第3の放送局
54 衛星の送信局
61 復号装置
62 逆多重化装置
63 取得部
64 逆多重化部

Claims (2)

  1. コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信部と、
    前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置に当該複数の第1の伝送単位を出力する復号部とを備え、
    前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は第1の基準クロック情報を含み、
    TMCC(Transmission and Multiplexing Configuration Control)制御情報の拡張領域は第2の基準クロック情報を含む、
    復号装置。
  2. コンテンツが多重化されることで得られた第1の伝送単位が1以上含まれる第2の伝送単位を複数格納した伝送用のフレームを受信する受信ステップと、
    前記伝送用のフレームを復号することで複数の前記第1の伝送単位を取得し、当該複数の第1の伝送単位を逆多重化することで前記コンテンツを取得する逆多重化装置に当該複数の第1の伝送単位を出力する復号ステップとを含み、
    前記伝送用のフレーム内の先頭の第2の伝送単位内で先頭に位置する第1の伝送単位は第1の基準クロック情報を含み、
    TMCC(Transmission and Multiplexing Configuration Control)制御情報の拡張領域は第2の基準クロック情報を含む、
    復号方法。
JP2020124518A 2014-08-27 2020-07-21 復号装置及び復号方法 Active JP7038311B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2022022546A JP7257648B2 (ja) 2014-08-27 2022-02-17 逆多重化装置及び逆多重化方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201462042367P 2014-08-27 2014-08-27
US62/042,367 2014-08-27

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2015149925A Division JP2016048912A (ja) 2014-08-27 2015-07-29 復号装置、逆多重化装置、復号方法及び逆多重化方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2022022546A Division JP7257648B2 (ja) 2014-08-27 2022-02-17 逆多重化装置及び逆多重化方法

Publications (2)

Publication Number Publication Date
JP2020174404A true JP2020174404A (ja) 2020-10-22
JP7038311B2 JP7038311B2 (ja) 2022-03-18

Family

ID=55649591

Family Applications (5)

Application Number Title Priority Date Filing Date
JP2015149925A Pending JP2016048912A (ja) 2014-08-27 2015-07-29 復号装置、逆多重化装置、復号方法及び逆多重化方法
JP2020124518A Active JP7038311B2 (ja) 2014-08-27 2020-07-21 復号装置及び復号方法
JP2022022546A Active JP7257648B2 (ja) 2014-08-27 2022-02-17 逆多重化装置及び逆多重化方法
JP2023046458A Active JP7450197B2 (ja) 2014-08-27 2023-03-23 受信装置及び受信方法
JP2024025777A Pending JP2024051039A (ja) 2014-08-27 2024-02-22 送信装置及び送信方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2015149925A Pending JP2016048912A (ja) 2014-08-27 2015-07-29 復号装置、逆多重化装置、復号方法及び逆多重化方法

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2022022546A Active JP7257648B2 (ja) 2014-08-27 2022-02-17 逆多重化装置及び逆多重化方法
JP2023046458A Active JP7450197B2 (ja) 2014-08-27 2023-03-23 受信装置及び受信方法
JP2024025777A Pending JP2024051039A (ja) 2014-08-27 2024-02-22 送信装置及び送信方法

Country Status (5)

Country Link
US (2) US10375436B2 (ja)
EP (1) EP3188490B1 (ja)
JP (5) JP2016048912A (ja)
CN (1) CN107079194B (ja)
WO (1) WO2016031172A1 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10462502B2 (en) 2014-11-21 2019-10-29 Sony Corporation Transmitting apparatus, transmitting method, receiving apparatus, and receiving method
US10085051B2 (en) * 2015-02-13 2018-09-25 Samsung Electronics Co., Ltd. Method and apparatus for converting MMTP stream to MPEG-2TS
CN108141636B (zh) * 2015-10-07 2021-03-23 松下知识产权经营株式会社 接收装置以及接收方法
JP6950259B2 (ja) * 2017-04-20 2021-10-13 日本電気株式会社 同期処理システム、信号処理システム、同期処理方法、および同期処理用プログラム
CN110719534B (zh) * 2018-07-11 2022-03-04 上海交通大学 基于广播系统的传输协议转换方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011103568A (ja) * 2009-11-11 2011-05-26 Nippon Hoso Kyokai <Nhk> 可変長パケットの送信装置、受信装置及びプログラム
WO2014188960A1 (ja) * 2013-05-23 2014-11-27 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
JP2016032236A (ja) * 2014-07-30 2016-03-07 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7324972B1 (en) * 1997-03-07 2008-01-29 Clickshare Service Corporation Managing transactions on a network: four or more parties
JP3731465B2 (ja) * 2000-10-13 2006-01-05 株式会社ケンウッド ディジタル放送受信機及びディジタル放送受信方法
KR101315454B1 (ko) * 2007-01-11 2013-10-04 삼성전자주식회사 디스플레이장치 및 그 제어방법
KR101874433B1 (ko) * 2011-06-16 2018-07-06 삼성전자주식회사 디지털 방송 시스템에서 방송 서비스 수신을 위한 시그널링 정보를 송수신하는 방법 및 장치
CN105308974B (zh) * 2013-06-21 2019-09-24 索尼公司 传输装置、传输方法、再现装置、再现方法以及接收装置
JP5708866B1 (ja) * 2014-04-10 2015-04-30 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011103568A (ja) * 2009-11-11 2011-05-26 Nippon Hoso Kyokai <Nhk> 可変長パケットの送信装置、受信装置及びプログラム
WO2014188960A1 (ja) * 2013-05-23 2014-11-27 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
JP2016032236A (ja) * 2014-07-30 2016-03-07 ソニー株式会社 送信装置、送信方法、受信装置および受信方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"高度広帯域衛星デジタル放送の伝送方式 TRANSMISSION SYSTEM FOR ADVANCED WIDE BAND DIGITAL SATELLITE B", 標準規格 ARIB STD-B44, vol. 2.0版, JPN6021015551, 31 July 2014 (2014-07-31), JP, pages 1 - 83, ISSN: 0004494449 *

Also Published As

Publication number Publication date
US20190306560A1 (en) 2019-10-03
CN107079194B (zh) 2020-06-30
JP2022059047A (ja) 2022-04-12
JP2016048912A (ja) 2016-04-07
US10375436B2 (en) 2019-08-06
JP2024051039A (ja) 2024-04-10
JP2023068133A (ja) 2023-05-16
US20170155947A1 (en) 2017-06-01
JP7450197B2 (ja) 2024-03-15
EP3188490A1 (en) 2017-07-05
CN107079194A (zh) 2017-08-18
EP3188490B1 (en) 2020-09-30
US10887649B2 (en) 2021-01-05
JP7257648B2 (ja) 2023-04-14
EP3188490A4 (en) 2017-07-05
JP7038311B2 (ja) 2022-03-18
WO2016031172A1 (ja) 2016-03-03

Similar Documents

Publication Publication Date Title
JP7072097B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP7073559B2 (ja) 送信方法、受信方法、送信装置、及び受信装置
JP6846644B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6827223B2 (ja) 送信方法、受信方法、送信装置及び受信装置
JP6300134B1 (ja) 送信方法、送信装置及びシステム
JP7038311B2 (ja) 復号装置及び復号方法
JP2022105570A (ja) 送信方法、受信方法、送信装置、及び受信装置
JP2022103269A (ja) 送信方法、受信方法、送信装置、及び受信装置
JP2024069460A (ja) 送信方法、受信方法、送信装置及び受信装置
WO2016056201A1 (ja) 送信方法、送信装置及びシステム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200721

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210326

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210427

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20210625

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210825

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: 20220118

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220217

R151 Written notification of patent or utility model registration

Ref document number: 7038311

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151