TWI661728B - 收訊裝置、及資料處理方法 - Google Patents

收訊裝置、及資料處理方法 Download PDF

Info

Publication number
TWI661728B
TWI661728B TW107106779A TW107106779A TWI661728B TW I661728 B TWI661728 B TW I661728B TW 107106779 A TW107106779 A TW 107106779A TW 107106779 A TW107106779 A TW 107106779A TW I661728 B TWI661728 B TW I661728B
Authority
TW
Taiwan
Prior art keywords
packet
plp
preamble
processing
demodulation
Prior art date
Application number
TW107106779A
Other languages
English (en)
Other versions
TW201836347A (zh
Inventor
岡田諭志
高橋和幸
大野武司
Original Assignee
日商索尼半導體解決方案公司
日商索尼股份有限公司
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 日商索尼半導體解決方案公司, 日商索尼股份有限公司 filed Critical 日商索尼半導體解決方案公司
Publication of TW201836347A publication Critical patent/TW201836347A/zh
Application granted granted Critical
Publication of TWI661728B publication Critical patent/TWI661728B/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/42—Arrangements for resource management
    • H04H20/426—Receiver side
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
    • H04B1/06—Receivers
    • H04B1/16—Circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/29—Arrangements for monitoring broadcast services or broadcast-related services
    • H04H60/32—Arrangements for monitoring conditions of receiving stations, e.g. malfunction or breakdown of receiving stations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/37—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying segments of broadcast information, e.g. scenes or extracting programme ID
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/68—Systems specially adapted for using specific information, e.g. geographical or meteorological information
    • H04H60/73—Systems specially adapted for using specific information, e.g. geographical or meteorological information using meta-information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42615—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific demultiplexing arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6112—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving terrestrial transmission, e.g. DVB-T
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/63—Control 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/643—Communication protocols
    • H04N21/64322—IP

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)

Abstract

本技術係有關於，使得收訊側的電路實作變為容易的收訊裝置、及資料處理方法。 　　提供一種收訊裝置，其將按照播送訊號中所含之複數PLP之每一者所獲得之封包予以解調的解調部、和將已被解調部所解調之封包加以處理的處理部，是透過單一或少於PLP之個數的介面而被連接，解調部，係在按照PLP之每一者所得之封包之中，對特定之封包，附加可用來識別封包所屬之PLP的識別資訊；處理部，係基於從特定之封包所得之識別資訊，來識別從解調部透過單一或少於PLP之個數的介面而被輸入的封包所隸屬的PLP。本技術係可適用於例如電視受像機。

Description

收訊裝置、及資料處理方法
本技術係有關於收訊裝置、及資料處理方法，尤其是有關於，可使得收訊側的電路實作變為容易的收訊裝置、及資料處理方法。
例如，在次世代地表播送規格之1的ATSC (Advanced Television Systems Committee)3.0中，資料傳輸時，已經決定主要不是採用TS(Transport Stream)封包，而是採用IP/UDP，亦即，含有UDP(User Datagram Protocol)封包的IP(Internet Protocol)封包的方式(以下稱為IP傳輸方式)。又，在ATSC3.0以外的播送方式中也是，期待在將來會採用IP傳輸方式。
又，在DVB-T2(Digital Video Broadcasting - Second Generation Terrestrial)所規定的M-PLP(Multiple PLP)方式中，於收訊側，進行傳輸串流(TS)之復原處理的前段之電路、與進行解碼等之處理的後段之電路之間，係以單一介面來加以實現(例如參照非專利文獻1)。 [先前技術文獻] [非專利文獻]
[非專利文獻1] ETSI EN 302 755 V1.3.1 (2011-11)
[發明所欲解決之課題]
可是，即使在採用了IP傳輸方式的情況下，仍由於成本面的考量，而是與DVB-T2同樣地，在收訊側的解調元件(解調LSI)、與其後段之單晶片系統(SoC：System on Chip)之間，係為較少的介面，較為理想。
如此，雖然藉由以較少的介面而被連接，是可以較少的成本來構成收訊側的電路，但若考慮實際的實作，則期望收訊側的電路實作係為容易。
本技術係有鑑於此種狀況而研發，其目的在於，使得收訊側的電路實作變為容易。 [用以解決課題之手段]
本技術之一側面之收訊裝置，係為一種收訊裝置，其係具備：解調部，係將按照播送訊號中所含之複數PLP(Physical Layer Pipe)之每一者所獲得之封包予以解調；和處理部，係將已被前記解調部所解調之前記封包，加以處理；前記解調部與前記處理部，係透過單一或少於PLP之個數的介面而被連接；前記解調部，係在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊；前記處理部，係基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP。
本技術之一側面的收訊裝置，係可為獨立的裝置，或可為構成1台裝置的內部區塊。又，本技術之一側面的資料處理方法，係為對應於上述本技術之一側面的收訊裝置的資料處理方法。
本技術之一側面的收訊裝置、及資料處理方法中，將按照播送訊號中所含之複數PLP之每一者所獲得之封包予以解調的解調部、和將已被前記解調部所解調之前記封包加以處理的處理部，是透過單一或少於PLP之個數的介面而被連接。又，在前記解調部側，係在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊；在前記處理部側，係基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP。 [發明效果]
若依據本技術之一側面，則可使收訊側的電路實作變得容易。
此外，並非一定限定於這裡所記載的效果，亦可為本揭露中所記載之任一效果。
以下，參照圖式，說明本技術的實施形態。此外，說明是按照以下順序進行。
1.系統之構成 　　2.第1實施形態 　　(1)對同一PLP之開頭的封包的附加方式 　　(2)對分割封包時的附加方式 　　3.第2實施形態 　　(1)對CID的對映方式 　　(2)對PID的對映方式 　　4.變形例 　　5.電腦之構成
＜1.系統之構成＞
(播送系統之構成例) 　　圖1係適用了本技術的播送系統之構成例的區塊圖。此外，所謂系統，係指由複數裝置做邏輯性集合而成者。
於圖1中，播送系統1係由送訊裝置10、和收訊裝置20所構成。在此播送系統1中，會進行符合所定之播送方式的資料傳輸。
送訊裝置10，係對被輸入至此的內容(例如播送節目等)之資料，實施調變或錯誤訂正等之處理，將其結果所得之播送訊號，以送訊所的送訊用天線予以發送。
來自送訊裝置10的播送訊號，係透過傳輸路30，透過末端使用者的各家庭等中所被設置的收訊用天線，而被電視受像機等之收訊裝置20所接收。收訊裝置20，係將透過傳輸路30而被接收的播送訊號，加以處理，將其結果所得之內容(例如播送節目等)的映像或聲音之資料，予以輸出。
此外，於播送系統1中，傳輸路30，係除了地表波(地表波播送)以外，亦可為例如：利用播送衛星(BS：Broadcasting Satellite)或通訊衛星(CS：Communications Satellite)的衛星播送、或使用纜線的有線播送(CATV：Common Antenna TeleVision)等。
(送訊裝置之構成例) 　　圖2係圖1之送訊裝置10的構成例的區塊圖。
送訊裝置10，係為支援IP傳輸方式的送訊機，將含有播送節目等之內容的播送串流，透過傳輸路30而予以發送。於圖2中，送訊裝置10係含有多工器111及調變部112而被構成。
多工器111，係將被輸入至此的複數IP串流，加以處理，然後供給至調變部112。此外，在ATSC3.0的情況下，對應於PLP(Physical Layer Pipe)，在每一所定之頻帶，最多會有64個IP串流被輸入。
調變部112，係對從多工器111所被供給的複數IP串流，進行錯誤訂正編碼處理或調變處理等之實體層(PHY)之相關處理，將該處理之結果所得之訊號，透過送訊所的送訊用天線，以播送訊號的方式予以發送。
送訊裝置10係被構成如上。
此外，在圖2所示的構成中，雖然圖示了，送訊裝置10係為單獨地，具有多工器111及調變部112的構成，但在一般的播送系統中，會有多工器111與調變部112是被設置在不同場所的情況。例如，多工器111係可以被設在，被配置於各播送台內的資料處理裝置(未圖示)中，而另一方面，調變部112係可以被設在，被配置於送訊所的資料處理裝置(未圖示)中。
又，於圖2中，作為資料傳輸之方式，是採用IP傳輸方式，圖示了將IP串流加以處理的構成，但不限於IP傳輸方式，亦可採用例如MPEG2-TS(Transport Stream)方式等其他方式。在採用MPEG2-TS方式的情況下，在送訊裝置10中，是取代IP串流，改成對TS串流進行處理。
(收訊裝置之構成例) 　　圖3係圖1的收訊裝置20之構成例的區塊圖。
收訊裝置20，係為支援IP傳輸方式的收訊機，將從送訊裝置10透過傳輸路30而被發送過來的播送串流予以接收，將播送節目等之內容予以再生。於圖3中，收訊裝置20係含有解調部211及處理部212而被構成。
此處，解調部211係例如，以RF IC或解調LSI等之解調元件的方式，而被構成。又，處理部212係例如，以單晶片系統(SoC：System On Chip)等的方式而被構成。亦即，在收訊裝置20中，解調部211與處理部212，是以不同的晶片(Chip)，而被構成。
解調部211，係對被輸入至此的訊號，進行解調處理或錯誤訂正解碼處理等之實體層(PHY)之相關處理、封包之相關處理等，將該處理之結果所得之1個ALP串流，透過單一介面(I/F)，輸出至後段的處理部212。
解調部211，係由訊框處理部231、FEC處理部232-1乃至232-4、及解調多工器233所構成。
訊框處理部231，係將從透過收訊用天線221而被接收之播送訊號所得之實體層訊框，加以處理，將其結果所得之資料，按照每一PLP，供給至FEC處理部232-1乃至232-4之其中一者。
FEC處理部232-1，係對從訊框處理部231按照每一PLP而被輸入的資料，實施錯誤訂正解碼處理，將其結果所得之資料，供給至解調多工器233。又，FEC處理部232-2乃至232-4，係和FEC處理部232-1同樣地，進行錯誤訂正解碼處理，將其結果所得之資料，供給至解調多工器233。
解調多工器233，係將從FEC處理部232-1乃至232-4按照每一PLP而被輸入之串流，加以處理，將其結果所得之1個ALP串流，透過單一介面(I/F)，輸出至處理部212。
處理部212，係將透過單一介面(I/F)而從前段的解調部211所被輸入的1個ALP串流，加以處理，將已被選台之播送節目(程式)所對應之IP串流，輸出至後段的電路(未圖示)。此外，在後段的電路中，會進行將IP串流中所含之視訊或音訊之資料予以解碼的處理等，已被選台之播送節目等之內容，會被再生。
處理部212，係由解多工器241、及封裝化解除部242-1乃至242-4所構成。
解多工器241，係將被輸入至此之1個ALP串流中所含之ALP封包，加以處理，將其結果所得之ALP串流，按照每一PLP，供給至封裝化解除部242-1乃至242-4之其中一者。
封裝化解除部242-1，係對從解多工器241按照每一PLP而被輸入的ALP串流，實施封裝化解除處理(Decap)，將其結果所得之IP串流，輸出至後段的電路。又，封裝化解除部242-2乃至242-4，係和封裝化解除部242-1同樣地，進行封裝化解除處理(Decap)，將其結果所得之IP串流，輸出至後段的電路。
收訊裝置20係被構成如上。
此外，收訊裝置20係亦可以：電視受像機或機上盒(STB：Set Top Box)、個人電腦、遊戲機等之固定收訊機，或是智慧型手機或行動電話機、平板型電腦等之行動收訊機的方式，而被構成。甚至，收訊裝置20，係亦可為頭戴式顯示器(HMD：Head Mounted Display)等之可穿戴電腦。
又，於圖3中，作為資料傳輸之方式，是採用IP傳輸方式，圖示了將IP串流加以處理的構成，但不限於IP傳輸方式，亦可採用例如MPEG2-TS方式等其他方式。在採用MPEG2-TS方式的情況下，在收訊裝置20中，是取代IP串流，改成對TS串流進行處理。
＜2.第1實施形態＞
順便一提，在一般的收訊機中，解調元件與單晶片系統(SoC)之間，一般都會對應於含有播送節目等之內容的串流，而設有複數個介面(I/F)。
例如，在次世代地表播送規格之1的ATSC3.0中，雖然在資料傳輸是使用含有UDP(User Datagram Protocol)封包的IP(Internet Protocol)封包，但在送訊機，係每一所定之頻帶，最多支援64個PLP(Physical Layer Pipe)。
另一方面，在一般的收訊機中，必須同時接收最多4個PLP。如此，在收訊機中，能夠同時接收複數PLP，藉此，例如，可每一PLP地變更調變方式或編碼方式(編碼率)等，可提供具有較高強固性的聲音、或較高品質的映像等。
而且，在ATSC3.0的情況下，對應於PLP，在每一所定之頻帶，最多會有64個IP串流被處理。該IP串流，係由IP封包所成之串流，含有播送節目等之內容所對應之視訊或音訊之組件、訊令等。
此情況下，在一般的收訊機中，係從解調元件所被輸出的4個IP串流，會被輸入至單晶片系統(SoC)，因此隨應於這些IP串流之數量，而需要4個介面(I/F)。
另一方面，在圖3的收訊裝置20中，作為解調元件的解調部211、與作為單晶片系統(SoC)的處理部212之間，是藉由單一介面(I/F)而被實現。
這是因為，在解調部211側，藉由對ALP封包，附加含有PLP_ID的PLP資訊，因此在處理部212側，係可基於從ALP封包所得之PLP_ID來識別，透過單一介面(I/F)而從解調部211所被輸入之ALP封包，是隸屬於哪個PLP。
(ALP封包的輸出時序) 　　接著，參照圖4乃至圖6，說明收訊裝置20中所被處理之ALP封包的輸出時序。
圖4中係圖示了，於收訊裝置20中，從解調部211對處理部212，透過單一介面(I/F)而被輸出之ALP封包的輸出時序。此外，於圖4中，橫方向係表示時間(Time)，縱方向係將訊框或封包處理所得之資料，按照每一階層而做階段性地表示。
於圖4中，最低層級之階層的資料，係為實體層訊框。例如，ATSC3.0中所被規定的實體層訊框，係由引導序列(Bootstrap)、前文(Preamble)、酬載(Payload)所構成。
在前文中係可含有例如：L1B訊令(L1-Basic Signaling)或L1D訊令(L1-Detail Signaling)等之實體層訊令。在此例中，係在前文中配置有，作為時刻資訊的PTP(Precision Time Protocol)。
此處，在圖5中係圖示了，被ATSC3.0所被規定之實體層訊框的結構之例子。於實體層訊框中，酬載(資料)，係被配置在子訊框。在實體層訊框處理之際，係在取得了引導序列與前文後，就可取得其後的子訊框。
此外，若含有2個以上之子訊框的情況下，則可每一子訊框地例如，變更FFT大小或保護區間長度、導頻型樣等之調變參數。
回到圖4的說明，於收訊裝置20的解調部211中，係藉由訊框處理部231及FEC處理部232，而將實體層訊框加以處理，從子訊框抽出1或複數個BB封包(Baseband Packet，以下亦記作「BBP」)。
又，於解調部211中，係藉由解調多工器233，而將BB封包加以處理，抽出1或複數個ALP封包。此時，解調多工器233，係會對ALP封包，附加含有PLP_ID的PLP資訊。
藉此，從解調部211對處理部212，透過單一介面(I/F)而被輸出之ALP封包，係被附加有PLP_ID，因此，在處理部212中，係可基於每一ALP封包所被附加的PLP_ID來識別，透過單一介面(I/F)而從解調部211所被輸入之ALP封包，是隸屬於哪個PLP。
此處，參照圖6，說明ALP封包的結構。
圖6的A係為通常的ALP封包之結構的圖示。於圖6的A中，通常的ALP封包，係由ALP標頭(ALP Packet Header)與酬載(Payload)所構成，
在ALP標頭之開頭，係被設定有3位元的Type。該Type係被設定了，ALP封包的酬載中所被配置的資料之類型的相關資訊。
於ALP標頭中，在Type之後，係被配置有1位元的PC(Payload Configuration)。作為PC是被設定"0"的情況下，隨應於其後所被配置的1位元的HM(Header Mode)，而變成單一封包模式(Single packet mode)，在ALP標頭中係被配置有，11位元的Length、或ALP擴充標頭(Additional header)。
在通常的ALP封包的情況下，作為HM是被設定"0"，在ALP標頭中，在HM的後續，配置有11位元的Length。又，於通常的ALP封包中，係於ALP標頭的後續，配置酬載。
圖6的B係為，對ALP擴充標頭，附加有PLP_ID時的ALP封包(以下亦稱為附帶PLP_ID之ALP封包)之結構的圖示。
於附帶PLP_ID之ALP封包中，在ALP標頭係配置有3位元的Type、1位元的PC、1位元的HM，作為HM，是被設定"1"。作為HM是被設定了"1"的情況下，在11位元的Length的後續，會被配置有ALP擴充標頭(Additional header)。
該ALP擴充標頭(Additional header)，係由：5位元的Length_MSB、1位元的RSV(reserved)、1位元的SIF(Sub-stream Identifier Flag)、1位元的HEF(Header Extension Flag)所構成。
Length_MSB，係將ALP封包之總酬載長度的最上位位元(MSB)以位元組單位加以表示，與ALP標頭的11位元的Length所示的最下位位元(LSB)做連結，就可獲得總酬載長度。
SIF係為表示，子串流用之選用標頭(Optional header)是否有被配置的旗標。作為SIF是被設定了"0"的情況下，係意味著選用標頭未被配置。
HEF係為表示，選用的標頭擴充是否有被進行的旗標。作為HEF是被設定了"1"的情況下，則標頭擴充是有被進行。圖6的B的附帶PLP_ID之ALP封包的ALP標頭中，係對ALP擴充標頭，進行了3位元組的標頭擴充。
該標頭擴充中係被配置有：8位元的Extension_type、8位元的Extension_length、6位元的PLP_ID、2位元的空白資料(dummy)。在此例中，作為私人使用者資料(PUD：Private User Data)，係被配置有6位元的PLP_ID，因此，對應於此配置的類型與長度之值，係分別被設定至Extension_type與Extension_length。
此外，作為該PLP_ID係對應於例如，在ATSC3.0中，被規定在L1D訊令(L1-Detail Signaling)的6位元的L1D_plp_id。關於L1D訊令的細節，係被揭露於下記的非專利文獻2。又，關於ALP封包之結構的細節，係被揭露於下記的非專利文獻3。
非專利文獻2：ATSC Standard：Physical Layer Protocol (A/322) 　　非專利文獻3：ATSC Standard：Link-Layer Protocol (A/330)
(1)對同一PLP之開頭的封包的附加方式
(PLP_ID的附加時序) 　　圖7係對透過單一介面(I/F)而被輸出的ALP封包的，PLP_ID的附加時序之例子的圖示。
此處，為了比較，將使用了現況之方式時的PLP_ID的附加時序，示於圖7的A，將使用了本技術之方式時的PLP_ID的附加時序，示於圖7的B。
如圖7的A所示，在現況之方式中，係每一ALP封包地，利用標頭擴充的私人使用者資料(PUD)，來附加PLP_ID。亦即，在現況之方式中，係對所有的ALP封包，都附加PLP_ID。
因此，由於是每一ALP封包地，附加由6位元組的資訊所構成之PLP_ID，因此解調部211與處理部212之間的單一介面(I/F)中的傳輸速率，係會上升。例如，由6位元組所成之ALP封包若為連續的情況下，則附加了PLP_ID時的傳輸速率，係變成2倍。
於是，在本技術之方式中，係提出一種用來抑制如此單一介面(I/F)中的傳輸速率之上升所需之技術。亦即，在本技術之方式中，在同一PLP_ID之ALP封包係為連續的情況下，則只對開頭之ALP封包，附加PLP_ID，對其以後之ALP封包，係不附加PLP_ID。
例如，如圖7的B所示，從PLP_ID = 1之PLP起連續獲得的ALP封包之中，只有對開頭之ALP封包，會利用標頭擴充的私人使用者資料(PUD)，來附加PLP_ID。又，跟對從PLP_ID = 2、3之PLP起連續獲得的ALP封包，也是同樣地，只對開頭之ALP封包，附加PLP_ID。
如此一來，於收訊裝置20中，在解調部211側，從同一PLP(PLP_ID = 1之PLP)起連續獲得的ALP封包之中，只有對開頭之ALP封包，會附加有PLP_ID(PLP_ID = 1)。
然後，在處理部212側，從被附加有某個PLP_ID(PLP_ID = 1)之ALP封包起，到被附加有另一PLP_ID(PLP_ID = 2)之ALP封包的前1個ALP封包為止的封包群，係可視為隸屬於同一PLP(PLP_ID = 1之PLP)中的ALP封包，而進行處理。
藉此，由於只需要對特定之ALP封包，附加最低限度的PLP_ID即可，因此可抑制解調部211與處理部212之間的單一介面(I/F)中的傳輸速率之上升。其結果為，可使收訊側的電路實作變得容易。
此外，如圖5所示的實體層訊框般地，在分時多工化方式(TDM：Time Division Multiplexing)的情況下，為了獲得每一PLP的訊號，在解調部211的解調多工器233中，可每一PLP地，取得連續的ALP封包。
又，例如，即使是分頻多工化方式(FDM)或分層多工化方式(LDM：Layered Division Multiplexing)等之分時多工化方式(TDM)的方式下，只要解調部211的解調多工器233具有緩衝記憶體，則只要在該緩衝記憶體中，將從各PLP所得之訊號加以記錄，然後每一PLP地，重新排列成連續的ALP封包即可。
又，上述的對ALP封包的PLP_ID之附加方式，係為一例，作為PLP_ID的附加方式，係可採用各式各樣的方式。例如，在上述的說明中，雖然說明了，是在ALP封包外，附加PLP_ID的情況，但亦可在ALP封包內，附加PLP_ID。又，例如，亦可不做ALP封包化，而將PLP_ID，附加在封包的開頭、最末尾、或中間。
甚至，PLP_ID，係亦可不是6位元的絕對性ID，而是例如，置換成2位元等之相對性ID，然後發送之。又甚至，PLP_ID所附加的封包，係不限於ALP封包，例如，亦可為IP封包或BB封包等之其他封包。
接著，參照圖8及圖9的流程圖，說明收訊側中所被執行的ALP封包之輸出入處理的細節。
(ALP封包輸出處理) 　　首先，參照圖8的流程圖，說明由收訊裝置20的解調部211所執行的解調部側ALP封包輸出處理之流程。
於步驟S101中，解調多工器233，係藉由將被輸入至此的BBP串流加以處理，以抽出ALP封包。
於步驟S102中，解調多工器233，係針對步驟S101之處理所抽出的ALP封包，判定呈現同一PLP_ID的ALP封包是否為連續。
於步驟S102中，呈現同一PLP_ID的ALP封包並未連續，亦即，判定其係為某個PLP中的開頭之ALP封包的情況下，則處理係前進至步驟S103。
於步驟S103中，解調多工器233，係對某個PLP中的開頭之ALP封包，利用標頭擴充的私人使用者資料(PUD)，來附加PLP_ID。一旦在步驟S103的處理中，對開頭之ALP封包，附加了PLP_ID，則處理係前進至步驟S104。
又，於步驟S102中，呈現同一PLP_ID的ALP封包係為連續，亦即，判定其係為某個PLP中的第2個以後的ALP封包的情況下，則步驟S103之處理係被略過，處理係前進至步驟S104。藉此，某個PLP中，對第2個以後之ALP封包，就不會附加PLP_ID。
於步驟S104中，解調部211的解調多工器233，係將ALP封包，透過單一介面(I/F)，輸出至處理部212。亦即，作為從解調多工器233所被輸出之ALP封包係為，對某個PLP中的開頭之ALP封包，是被附加有PLP_ID，對第2個以後之ALP封包，是未附加PLP_ID。
於步驟S105中，係判定對ALP封包之處理是否結束。步驟S105中，當判定為對ALP封包之處理未結束時，則處理會回到步驟S101，並重複其以後之處理。
例如，PLP，係藉由PLP_ID = 1、2、3、・・・等而被識別，但在PLP_ID = 1之PLP中，係對開頭之ALP封包，附加PLP_ID = 1，對第2個以後之ALP封包，係未附加PLP_ID。
又，同樣地，於PLP_ID = 2之PLP中，係只對開頭之ALP封包，附加PLP_ID = 2，於PLP_ID = 3之PLP中，係只對開頭之ALP封包，附加PLP_ID = 3。此外，由於重複因而省略其說明，但關於PLP_ID = 4以後也是同樣地處理。
另一方面，於步驟S105中，若判定對ALP封包之處理結束，則圖8的解調部側ALP封包輸出處理就被結束。
以上說明了解調部側ALP封包輸出處理之流程。
(ALP封包輸入處理) 　　接著，參照圖9的流程圖，說明由收訊裝置20的處理部212所執行的處理部側ALP封包輸入處理之流程。
於步驟S121中，解多工器241係取得，從解調部211透過單一介面(I/F)而被輸入的ALP封包。
於步驟S122中，解多工器241係判定，在步驟S121之處理所得之ALP封包的標頭擴充的私人使用者資料(PUD)中，是否有被附加PLP_ID。
於步驟S122中，判定為對ALP封包是有被附加PLP_ID的情況下，則處理係前進至步驟S123。於步驟S123中，解多工器241，係將步驟S122之處理中的判斷對象之ALP封包，視為相應於已被附加之PLP_ID的新的PLP之序列的ALP封包。
又，於步驟S122中，判定為對ALP封包並沒有被附加PLP_ID的情況下，則處理係前進至步驟S124。於步驟S124中，解多工器241，係將步驟S122之處理中的判斷對象之ALP封包，視為是與現時點的PLP_ID相同PLP之序列的ALP封包。
亦即，在解調部211側，係對某個PLP中的開頭的ALP封包是附加PLP_ID，對第2個以後之ALP封包是未附加PLP_ID，因此，在處理部212側，從已被附加有PLP_ID的ALP封包起，至下個有被附加PLP_ID的ALP封包的前1個ALP封包為止，係可視為同一PLP_ID之ALP封包是呈連續。
例如，於PLP_ID = 1之PLP中，係對開頭之ALP封包，附加PLP_ID = 1，因此將該當ALP封包，視為PLP_ID = 1之新的PLP之序列(S123)。其後，於PLP_ID = 1之PLP中，對第2個以後之ALP封包，係未附加PLP_ID，因此將該當ALP封包，視為現時點的PLP_ID，亦即，與PLP_ID = 1相同PLP之序列(S124)。
一旦步驟S123或S124之處理結束，則處理係前進至步驟S125。
於步驟S125中，解多工器241，係每一PLP之序列地，將ALP封包，輸出至封裝化解除部242。例如，PLP_ID = 1之PLP之序列的ALP封包係被輸出至，封裝化解除部242-1乃至242-4之中的封裝化解除部242-1。
於步驟S126中，係判定對ALP封包之處理是否結束。步驟S126中，當判定為對ALP封包之處理未結束時，則處理會回到步驟S121，並重複其以後之處理。
例如，於PLP_ID = 2之PLP中，開頭之ALP封包，係被附加有PLP_ID = 2，因此被視為PLP_ID = 2之新的PLP之序列(與現時點的PLP_ID不同的PLP之序列)(S123)，第2個以後之ALP封包，係未附加PLP_ID，因此，被視為現時點的PLP_ID，亦即，與PLP_ID = 2相同PLP之序列(S124)。然後，PLP_ID = 2之PLP之序列的ALP封包，係被輸出至封裝化解除部242-2(S125)。
此外，雖然重複因而省略其說明，但關於PLP_ID = 3、4以後也是同樣地被處理，已被附加有PLP_ID的ALP封包被取得時，就視為新的PLP之序列，例如，PLP_ID = 3之PLP之序列的ALP封包，係被輸出至封裝化解除部242-3，PLP_ID = 4之PLP之序列的ALP封包，係被輸出至封裝化解除部242-4。
另一方面，於步驟S126中，若判定對ALP封包之處理結束，則圖9的處理部側ALP封包輸入處理就被結束。
以上說明了處理部側ALP封包輸入處理之流程。
(2)對分割封包時的附加方式
順便一提，在ATSC3.0中，作為ALP封包，係規定有分段封包(Segmentation Packet)或串接封包(Concatenation Packet)。以下說明，在分段封包被利用時，PLP_ID附加之際的對應。
(ALP封包的結構) 　　圖10係ALP封包的結構之例子的圖示。
於圖10的ALP封包中，在ALP標頭之開頭，係配置有3位元的Type、1位元的PC(Payload Configuration)。作為PC是被設定"0"的情況下，隨應於其後所被配置的1位元的HM(Header Mode)，而變成單一封包模式(Single packet mode)，在ALP標頭中係被配置有11位元的Length或擴充標頭(Additional header)，這和之前所說明的相同。
另一方面，作為PC是被設定"1"的情況下，會隨應於其後配置的1位元的S/C (Segmentation/ Concatenation)，而變成分段模式(Segmentation mode)或串接模式(Concatenation mode)，而在ALP標頭中係配置11位元的Length或擴充標頭(Additional header)。
圖11中係圖示ALP標頭的語法之例子。此外，有關分段封包或串接封包之細節，係在非專利文獻3的「Figure 5.2 Structure of Base Header for ALP packet encapsulation.」、或「Table 5.1 Header Syntax for ALP Packet Encapsulation」等中，有記載其詳細內容。
(PLP_ID的附加時序) 　　圖12係對透過單一介面(I/F)而被輸出的ALP封包的，PLP_ID的附加時序之例子的圖示。
此處，為了比較，將使用了現況之方式時的PLP_ID的附加時序，示於圖12的A，將使用了本技術之方式時的PLP_ID的附加時序，示於圖12的B。
如圖12的A所示，在現況之方式中，無論ALP標頭的PC(Payload Configuration)之值為何，亦即，與單一封包模式、分段模式、串接模式等之ALP封包的種類無關，對所有的ALP封包，都會附加PLP_ID。
因此，由於是每一ALP封包地，附加由6位元組的資訊所構成之PLP_ID，因此解調部211與處理部212之間的單一介面(I/F)中的傳輸速率，係會上升，這和之前所說明的相同。
又，作為ALP標頭之PC是設定"1"的情況，且為分段模式時，IP封包係被分割，已被分割之IP封包的一部分會被傳輸。該已被分割之IP封包，係被當成ALP封包(分段封包)。
又，作為ALP標頭之PC是設定"1"的情況，且為串接模式時，複數個IP封包會被結合(連結)，已被結合之IP封包會被傳輸。該已被結合之IP封包，係被當成ALP封包(串接封包)。
此時，即使藉由ALP封包所內包的資訊(例如CID(Context Identifier)等)，而可識別PLP_ID，一旦發生ALP封包之分割，則可識別之資訊，係在已被分割之ALP封包(分段封包)之中，只會殘留在開頭之ALP封包(分段封包)中。
因此，若放任不管，則在已被分割之ALP封包(分段封包)之中，開頭之ALP封包(分段封包)以外的ALP封包(分段封包)，係沒有可以識別PLP_ID的方法。
於是，在本技術之方式中，作為ALP標頭之PC是被設定"1"，且作為ALP標頭之S/H是被設定"0"的情況下，對ALP封包(分段封包)，會附加PLP_ID。亦即，在本技術之方式中，係只對PC = 1之ALP封包(分段封包)，附加PLP_ID，對PC = 0之ALP封包，係不會附加PLP_ID。
例如，如圖12的B所示，PC = 0、1之ALP封包之中，只有對PC = 1之ALP封包，會利用標頭擴充的私人使用者資料(PUD)，來附加PLP_ID。藉此，在已被分割之ALP封包(分段封包)之中，不只開頭之ALP封包(分段封包)，就連其以外的ALP封包(分段封包)，也可參照標頭擴充的私人使用者資料(PUD)，來識別PLP_ID。
此外，此處雖然是以分段封包為中心來說明，但關於串接封包也是同樣地，可利用標頭擴充的私人使用者資料(PUD)，來附加PLP_ID。
＜3.第2實施形態＞
(1)對CID的對映方式
(IP資料流之例子) 　　圖13係IP傳輸方式所致之資料傳輸之構成之例子的圖示。
於圖13中，藉由廣播串流ID(BS_ID)而被識別的RF頻道中，係藉由1或複數個PLP(Physical Layer Pipe)，而傳輸含有各種封包的串流。
在圖13的例子中，是藉由PLP_ID = 0、1、2、3的4個PLP，而構成了1個服務。又，在各PLP中，若採用IP傳輸方式的情況，則串流是每一IP資料流地被傳輸。此處，所謂IP資料流，係為IP位址與埠號為相同的IP封包之集合。又，IP資料流，係藉由CID(Context Identifier)而被識別。
在圖13的例子中，在PLP_ID = 0之PLP中，係藉由2個IP資料流#0、#1，而將串流予以傳輸。同樣地，在PLP_ID = 1之PLP中，係藉由2個IP資料流#2、#3，而將串流予以傳輸；在PLP_ID = 2之PLP中，係藉由2個IP資料流#4、#5，而將串流予以傳輸；在PLP_ID = 3之PLP中，係藉由2個IP資料流#6、#7，而將串流予以傳輸。
對這些IP資料流，係分別被分配有CID，但以不同PLP而被傳輸的傳輸封包(例如後述的標頭有被壓縮之IP封包)中，若CID有重複時，則必須要藉由PLP_ID來判別IP資料流。
例如，在圖13的例子中，在PLP_ID = 0之PLP中，CID = 0之IP資料流#0會被傳輸，在PLP_ID = 3之PLP中，CID = 0之IP資料流#7會被傳輸，但此情況下，由於CID是0而為重複，因此會藉由0、3之PLP_ID，來判別各個IP資料流。
換言之，在同一服務內，若CID沒有重複，則即使沒有對傳輸封包附加PLP_ID，仍可特定出IP資料流。
例如，在圖13的例子中，於PLP_ID = 3之PLP中，將IP資料流#7之CID，不是設成0，而是設成7，藉此，在由4個PLP所構成的服務內，CID就會是固有之值，可不必用PLP_ID，就能特定出IP資料流。
順便一提，在IP資料流中所被傳輸的IP封包，係在標頭中會含有各式各樣的資訊，因此負擔會較大。於是，為了有效率地傳輸IP封包所需的，作為用來壓縮IP封包之標頭所需之技術，係有IETF(The Internet Engineering Task Force)在RFC3095中所規定的RoHC (Robust Header Compression)。
在RoHC中，將IP標頭與UDP標頭之標頭資訊全部加以含有的傳輸封包(完整的傳輸封包)係被發送，關於其後的傳輸封包之標頭資訊，係只有和前一個完整的傳輸封包之標頭資訊的差異資訊，會被發送。
亦即，RoHC，係將構成含有UDP封包之IP封包的IP標頭與UDP標頭中所被配置的標頭資訊，分離成靜態資訊(SC：Static Chain)與動態資訊(DC：Dynamic Chain)，藉由使得靜態資訊(SC)不被重複發送以減少其傳輸次數，而實現標頭資訊之壓縮的方式。
此外，此處，所謂靜態資訊(SC)，係指在標頭資訊之中，已被預先設定之內容不會有變化者，或無論狀況為何其內容都會維持一貫者。另一方面，所謂動態資訊(DC)，係指在標頭資訊之中，已被預先設定之內容是會隨著狀況而變化者，或可配合狀況而加以選擇而具有彈性者。
(IR封包的結構) 　　圖14係為封包類型是IR封包的傳輸封包的結構之例子的圖示。
圖14的傳輸封包的標頭中，從開頭起1位元組(1～8位元)中，係被配置有Add-CID octet。該Add-CID octet中，係被設定有PLP_ID或CID，但其詳細的結構，係參照圖17而於後述。
又，在後續的1位元組(9～16位元)之中，從開頭起7位元中，係被固定設定"1111110"，在最後的1位元中，係設定表示是否有動態資訊(DC)的旗標(D)。然後，後續的2位元組(17～24, 25～32位元)，係在CID為4位元以上的情況下，成為因應需要而被使用的擴充用之CID領域(large CID)。
又，在後續的1位元組(33～40位元)中，係被設定有8位元的設定檔(profile)。在圖14的傳輸封包中，係被設定有"0x0002"的設定檔。然後，在後續的1位元組(41～48位元)中，係被設定有8位元的錯誤偵測碼(CRC：Cyclic Redundancy Check)。在錯誤偵測碼(CRC)的後續，係被配置有可變長度的靜態資訊(SC)與動態資訊(DC)。
封包類型為IR封包的傳輸封包的標頭，係具有如上的結構，該標頭的後續，亦被配置有酬載(Payload)。
(IR-DYN封包的結構) 　　圖15係為封包類型是IR-DYN封包的傳輸封包的結構之例子的圖示。
圖15的傳輸封包的標頭中，從開頭起1位元組(1～8位元)中，係被配置有Add-CID octet。該Add-CID octet中，係被設定有PLP_ID或CID，但其詳細的結構，係參照圖17而於後述。
又，在後續的1位元組(9～16位元)中，係被固定設定"11111000"。然後，後續的2位元組(17～24, 25～32位元)，係在CID為4位元以上的情況下，成為因應需要而被使用的擴充用之CID領域(large CID)。
又，在後續的1位元組(33～40位元)中，係被設定有8位元的設定檔(profile)。在圖15的傳輸封包中，係被設定有"0x0002"的設定檔。然後，在後續的1位元組(41～48位元)中，係被設定有8位元的錯誤偵測碼(CRC)。在錯誤偵測碼(CRC)的後續，係被配置有可變長度的動態資訊(DC)。
封包類型為IR-DYN封包的傳輸封包的標頭，係具有如上的結構，該標頭的後續，亦被配置有酬載(Payload)。
(UO-0封包的結構) 　　圖16係為封包類型是UO-0封包的傳輸封包的結構之例子的圖示。可是，於圖16中，是將CID為15以下時的結構示於圖16的A，將CID為16以上時的結構示於圖16的B。
圖16的A的傳輸封包的標頭中，從開頭起1位元組(1～8位元)中，係被配置有Add-CID octet。
又，在後續的1位元組(9～16位元)之中，在開頭之1位元中，係被固定設定"0"。然後，在後續的4位元中，係被設定有SN(Sequence Number)，在後續的3位元中，係被設定有錯誤偵測碼(CRC)。
圖16的B的傳輸封包的標頭中，從開頭起1位元組(1～8位元)之中，在開頭之1位元中，係被固定設定"0"。然後，在後續的4位元中，係被設定有SN(Sequence Number)，在後續的3位元中，係被設定有錯誤偵測碼(CRC)。
後續的2位元組(9～16, 17～24位元)，係成為因應需要而被使用的擴充用之CID領域(large CID)。
此外，圖14乃至圖16所示的RoHC之封包類型係為一例，RoHC中係還規定有例如：UO-1、UOR-2封包等之其他封包類型。又，關於RoHC的封包類型，係在RoHC的規格書(RObust Header Compression (ROHC)：Framework and four profiles：RTP, UDP, ESP, and uncompressed)中，有描述其詳細內容。
在本技術中，係於IR封包或IR-DYN封包、UO-0封包等之傳輸封包中，在標頭的Add-CID octet之領域(以下亦稱為CID領域(small CID))、或擴充用之CID領域(large CID)，作為該當傳輸封包所屬之PLP之PLP_ID所被對映的對映資訊，是將CID領域資訊予以含入，藉此而可識別該當傳輸封包所屬之PLP。
以下，作為使用如此的CID領域資訊(對映資訊)，來識別傳輸封包所屬之PLP的方式，說明第1之CID對應方式乃至第4之CID對應方式的4種方式。
(1-1)第1種CID對應方式
(Add-CID octet的結構) 　　圖17係Add-CID octet的結構之例子的圖示。
在RoHC中係規定了，在圖14、圖15、圖16的A所示的傳輸封包的標頭中，在從開頭起1位元組(1～8位元)中，作為Add-CID octet，是設定"1110 CID"，亦即，在上位之4位元中，"1110"是被固定設定，在下位之4位元中，會被設定CID。
另一方面，在本技術中，在採用第1種CID對應方式的情況下，在Add-CID octet之CID領域中，是在下位之4位元的CID之中，對上位2位元，分配PLP_ID，對剩餘的2位元，分配CID。藉由如此所被分配的2位元的PLP_ID，在同一服務內，最多就可識別4個PLP。
此外，該CID領域中的位元的分配，係為一例，例如，可隨著欲識別的PLP之數量，來變更所分配的位元。
接著，參照圖18及圖19的流程圖，說明送訊側與收訊側中所被執行的CID對應處理的細節。
(第1送訊側CID對應處理) 　　首先，參照圖18的流程圖，說明由送訊裝置10所執行的第1送訊側CID對應處理之流程。
於步驟S201中，調變部112係將被輸入至此的傳輸封包加以處理，在其標頭的Add-CID octet的CID領域內的4位元之中，對上位2位元，配置PLP_ID。
亦即，作為被配置在CID領域內的CID領域資訊，是含有下位2位元的CID，以及2位元的PLP_ID。對如此所得之傳輸封包，實施調變處理等之必要的處理，其結果所得之播送訊號會被發送。
以上說明了第1送訊側CID對應處理之流程。
(處理部側CID對應處理) 　　其次，參照圖19的流程圖，說明被收訊裝置20所執行的處理部側CID對應處理之流程。
此外，圖19所示的處理，係於收訊裝置20中，藉由處理部212而被執行的處理，作為其前段的處理，是進行解調部211中的處理。亦即，藉由解調部211，對從送訊裝置10所接收到的播送訊號，實施解調處理等之必要的處理，其結果所得之ALP封包，係透過單一介面(I/F)而被輸出至處理部212。
於步驟S211中，解多工器241，係將被輸入至此之ALP封包，加以處理，而取得傳輸封包。該傳輸封包係為例如IR封包或IR-DYN封包、UO-0封包等。
於步驟S212中，解多工器241，係從步驟S211之處理所取得之傳輸封包的標頭(的Add-CID octet之CID領域)，抽出CID領域資訊。
於步驟S213中，解多工器241，係解析步驟S212之處理中所被抽出之CID領域資訊。
此處，於第1種CID對應方式中，作為從傳輸封包的標頭之CID領域所得之CID領域資訊，是在CID領域內的4位元之中，對上位2位元係被配置有PLP_ID，因此相應於該當PLP_ID的PLP之序列，會按照處理對象之每一傳輸封包而被特定。
於步驟S214中，解多工器241，係基於步驟S213之處理中所得之解析結果，而每一PLP之序列地，將傳輸封包予以輸出。
於步驟S215中，係判定對傳輸封包之處理是否結束。步驟S215中，當判定為對傳輸封包之處理未結束時，則處理會回到步驟S211，並重複其以後之處理。
例如，PLP_ID = 1之PLP之序列的傳輸封包係被輸出至，封裝化解除部242-1等之第1處理序列。又，PLP_ID = 2之PLP之序列的傳輸封包係被輸出至，封裝化解除部242-2等之第2處理序列。然後，PLP_ID = 3、4以後也是同樣地，分別被輸出至第3處理序列或第4處理序列等之相應於PLP之序列的處理序列。
另一方面，於步驟S215中，若判定對傳輸封包之處理結束，則圖19的處理部側CID對應處理就被結束。
以上說明了處理部側CID對應處理之流程。
(1-2)第2種CID對應方式
在RoHC中，係於圖14、圖15、圖16的B所示的傳輸封包的標頭中，確保了擴充用之CID領域(Large CID)，因此在本技術中，採用第2種CID對應方式的情況下，會在該擴充用之CID領域中，配置PLP_ID。
此時，藉由確保2位元來作為PLP_ID，因此在同一服務內，最多就可識別4個PLP。又，相較於上述的第1種CID對應方式，從開頭起1位元組的Add-CID octet之CID領域中，係未分配PLP_ID，因此可將Add-CID octet，按照RoHC之規定而加以利用。但是，PLP_ID的位元數，係不限於2位元，可為任意之位元。
(第2送訊側CID對應處理) 　　此處，參照圖20的流程圖，說明由送訊裝置10所執行的第2送訊側CID對應處理之流程。
於步驟S221中，調變部112係將被輸入至此的傳輸封包加以處理，在其標頭的擴充用之CID領域中，配置2位元的PLP_ID。
藉此，作為被配置在CID領域、和擴充用之CID領域內的CID領域資訊，係可包含有Add-CID octet之CID，以及PLP_ID。對如此所得之傳輸封包，實施調變處理等之必要的處理，其結果所得之播送訊號會被發送。
以上說明了第2送訊側CID對應處理之流程。
此外，於第2種CID對應方式中，由收訊裝置20所執行的處理，係和上述的第1種CID對應方式基本相同，因此省略其詳細說明，但在以下幾點係有不同。
亦即，於收訊裝置20的處理部212中，係藉由解多工器241，取得被配置在擴充用之CID領域的PLP_ID，來作為從傳輸封包的標頭所得之CID領域資訊。藉此，解多工器241，係可按照該PLP_ID所相應之PLP之序列之每一者，將傳輸封包予以輸出。
(1-3)第3種CID對應方式
在RoHC中，係於圖14、圖15、圖16所示的傳輸封包的標頭中，在CID領域或擴充用之CID領域中，配置CID，但在本技術中，在採用第3種CID對應方式的情況下，則是藉由送訊側的送訊裝置10進行管理，以使得在由複數PLP所構成的1個服務內，CID不會重複。
(第3送訊側CID對應處理) 　　此處，參照圖21的流程圖，說明由送訊裝置10所執行的第3送訊側CID對應處理之流程。
於步驟S231中，調變部112，係將被輸入至此的傳輸封包加以處理，在其標頭的CID領域或擴充用之CID領域中，設定CID之際，係進行管理，以使得由複數PLP所構成的1個服務內，CID不會重複。
此處，例如，調變部112係在內建的記憶體中，記錄CID管理用的表格，一面參照該當表格，一面管理處理對象之服務內所被使用的CID，藉此以使得CID不會重複。
例如，在上述的圖13的例子中，構成1個服務的4個PLP(PLP_ID = 0、1、2、3之PLP)之每一者，分別有2個IP資料流會被傳輸，但會藉由調變部112，對各IP資料流，分配固有的CID。
更具體而言，如圖13的例子所示，對IP資料流#0乃至#7，作為CID，是依序分配0至7之值，藉此，在由4個PLP所構成的服務內，CID就會是固有之值，就可沒有PLP_ID，也能特定出IP資料流。
亦即，作為傳輸封包的標頭之CID領域或擴充用之CID領域內的CID領域資訊是含有：在送訊側之送訊裝置10中被管理成不會重複的CID。對如此所得之傳輸封包，實施調變處理等之必要的處理，其結果所得之播送訊號會被發送。
以上說明了第3送訊側CID對應處理之流程。
此外，於第3種CID對應方式中，由收訊裝置20所執行的處理，係和上述的第1種CID對應方式基本相同，因此省略其詳細說明，但在以下幾點係有不同。
亦即，於收訊裝置20的處理部212中，係藉由解多工器241，作為從傳輸封包的標頭之CID領域或擴充用之CID領域所得之CID領域資訊，會獲得在送訊側之送訊裝置10中被管理成不會重複的CID。藉此，解多工器241，係可按照CID所相應之IP資料流之序列(PLP之序列)之每一者，將傳輸封包予以輸出。
(1-4)第4種CID對應方式
在RoHC中，係於圖14、圖15、圖16所示的傳輸封包的標頭中，在CID領域或擴充用之CID領域中，配置CID，但在本技術中，在採用第4種CID對應方式的情況下，則是藉由收訊側的收訊裝置20(的解調部211)進行管理，以使得在由複數PLP所構成的1個服務內，CID不會重複。
(解調部側CID對應處理) 　　此處，參照圖22的流程圖，說明被收訊裝置20所執行的解調部側CID對應處理之流程。
於步驟S241中，解調多工器233，係將被輸入至此的傳輸封包加以處理，在辨識其標頭的CID領域或擴充用之CID領域中所被設定的CID之際，係進行管理，以使得由複數PLP所構成的1個服務內，CID不會重複。
亦即，解調多工器233，係在由複數PLP所構成的1個服務內，若有CID重複，則置換成不重複的CID。此處，例如，解調多工器233係在內建的記憶體中，記錄CID管理用的表格，一面參照該當表格，一面管理處理對象之服務內所被使用的CID，藉此以使得CID不會重複。
例如，在上述的圖13的例子中，構成1個服務的4個PLP(PLP_ID = 0、1、2、3之PLP)之每一者，分別有2個IP資料流會被傳輸，但會藉由解調多工器233，對各IP資料流，分配固有的CID。
更具體而言，如圖13的例子所示，在送訊側之送訊裝置10中CID未被管理，對IP資料流#0乃至#7，作為CID，是依序分配了0、1、2、3、4、5、6、0之值的情況下，則由解調多工器233，將IP資料流#7之CID，置換成0至7。藉此，在由4個PLP所構成之服務內，CID會變成固有之值，在處理部212側，就可沒有PLP_ID，仍可特定出IP資料流。
此外，於第4種CID對應方式中，由處理部212所執行的處理，係和上述的第1種CID對應方式基本相同，因此省略其詳細說明，但在以下幾點係有不同。
亦即，於收訊裝置20的處理部212中，係藉由解多工器241，作為從傳輸封包的標頭之CID領域或擴充用之CID領域所得之CID領域資訊，會獲得在收訊側(的解調部211)被管理成不會重複的CID。藉此，解多工器241，係可按照CID所相應之IP資料流之序列(PLP之序列)之每一者，將傳輸封包予以輸出。
如以上所述，藉由在IR封包等之傳輸封包的標頭之CID領域(small CID)或擴充用之CID領域(large CID)中，配置作為PLP_ID之對映資訊的CID領域資訊，就可在收訊側，使用該當CID領域資訊，來識別傳輸封包所屬之PLP。
又，不需要將相當於PLP_ID的資訊，對映至其他領域(CID領域或擴充用之CID領域)，例如，不需要對ALP封包附加PLP_ID，因此，在收訊側的收訊裝置20中，作為解調元件的解調部211、和作為單晶片系統(SoC)的處理部212之間的單一介面(I/F)中的傳輸速率之上升，可被抑制。其結果為，可使收訊側的電路實作變得容易。
此外，如上述，例如，在ATSC3.0中，在資料傳輸上，是採用使用含有UDP封包之IP封包的IP傳輸方式，因此，可以適用如上述的對CID的對映方式。又，即使是ATSC3.0以外的播送方式，只要是在採用了IP傳輸方式的播送方式中，仍可以適用對CID的對映方式。
又，上述的說明中，送訊側的CID之相關處理，是假設成例如，由被設置在送訊所側的(資料處理裝置的)調變部112(處理部)所執行來做說明，但送訊側的CID之相關處理，係亦可由被設置在播送台側的(資料處理裝置的)多工器111(處理部)來執行。
再者，在ATSC3.0中，CID雖然被規定成到1位元組為止，但在本技術中，並沒有如此的限定，例如也可包含CID為2位元組的情況。
(2)對PID的對映方式
(TS封包的結構) 　　圖23係TS封包的語法之例子的圖示。
符合MPEG-2 TS(Transport Stream)方式的TS串流，係由TS封包所構成。該TS封包的標頭係由含有：8位元的sync_byte、1位元的transport_error_indicator、1位元的payload_unit_start_indicator、1位元的transport_priority、13位元的PID、2位元的transport_scrambling_control、2位元的adaptation_field_control、4位元的continuity_counter的32位元所成。
此處，13位元的PID(Packet ID)，係為被分配給符合MPEG-2 TS之TS封包之每一者的封包識別元。該封包識別元，係為用來表示各TS封包之每一者正在傳輸什麼東西所需之識別元。
在本技術中，係於TS封包中，在標頭的PID之領域，作為該當TS封包所屬之PLP的PLP_ID所被對映的對映資訊，是將PID領域資訊予以含入，藉此而可識別該當TS封包所屬之PLP。
以下，作為使用如此的PID領域資訊(對映資訊)，來識別TS封包所屬之PLP的方式，說明第1之PID對應方式乃至第3之PID對應方式的3種方式。
此外，在對PID的對映方式中，由於會變成將由TS封包所構成之TS串流加以處理，因此送訊側的送訊裝置10(圖2)、收訊側的收訊裝置20(圖3)中，係取代IP串流，改為將TS串流加以處理。
(2-1)第1種PID對應方式
(PID的結構) 　　圖24係PID的結構之例子的圖示。
於TS封包的標頭中，對PID係分配有13位元，這是如同之前所說明。在本技術中，在採用第1種PID對應方式的情況下，係在13位元的PID之中，對上位2位元分配PLP_ID，對剩餘的11位元分配PID。藉由如此所被分配的2位元的PLP_ID，在同一服務內，最多就可識別4個PLP。
接著，參照圖25及圖26的流程圖，說明送訊側與收訊側中所被執行的PID對應處理的細節。
(第1送訊側PID對應處理) 　　首先，參照圖25的流程圖，說明由送訊裝置10所執行的第1送訊側PID對應處理之流程。
於步驟S301中，調變部112係將被輸入至此的TS封包加以處理，在其標頭的PID的13位元之中，對上位2位元，配置PLP_ID。
藉此，作為在TS封包的標頭的PID之領域內所被配置之PID領域資訊，係可包含有下位11位元的PID，以及2位元的PLP_ID。對如此所得之TS封包，實施調變處理等之必要的處理，其結果所得之播送訊號會被發送。
以上說明了第1送訊側PID對應處理之流程。
(處理部側PID對應處理) 　　其次，參照圖26的流程圖，說明被收訊裝置20所執行的處理部側PID對應處理之流程。
此外，圖26所示的處理，係於收訊裝置20中，藉由處理部212而被執行的處理，作為其前段的處理，是進行解調部211中的處理。亦即，藉由解調部211，對從送訊裝置10所接收到的播送訊號，實施解調處理等之必要的處理，其結果所得之TS封包，係透過單一介面(I/F)而被輸出至處理部212。
於步驟S311中，解多工器241，係將被輸入至此之TS封包，加以取得。
於步驟S312中，解多工器241，係從步驟S311之處理所取得之TS封包的標頭的PID領域，抽出PID領域資訊。
於步驟S313中，解多工器241，係解析步驟S312之處理中所被抽出之PID領域資訊。
此處，於第1種PID對應方式中，作為從TS封包的標頭之PID領域所得之PID領域資訊，是在13位元的資訊之中，對上位2位元係被配置有PLP_ID，因此相應於該當PLP_ID的PLP之序列，會按照處理對象之每一TS封包而被特定。
於步驟S314中，解多工器241，係基於步驟S313之處理中所得之解析結果，而每一PLP之序列地，將TS封包予以輸出。
於步驟S315中，係判定對TS封包之處理是否結束。步驟S315中，當判定為對TS封包之處理未結束時，則處理會回到步驟S311，並重複其以後之處理。
例如，PLP_ID = 1之PLP之序列的TS封包係被輸出至，封裝化解除部242-1等之第1處理序列。又，PLP_ID = 2之PLP之序列的TS封包係被輸出至，封裝化解除部242-2等之第2處理序列。然後，PLP_ID = 3、4以後也是同樣地，分別被輸出至第3處理序列或第4處理序列等之相應於PLP之序列的處理序列。
另一方面，於步驟S315中，若判定對TS封包之處理結束，則圖26的處理部側PID對應處理就被結束。
以上說明了處理部側PID對應處理之流程。
(2-2)第2種PID對應方式
在MPEG2-TS方式中，係於圖23所示的TS封包的標頭中，在PID領域中，配置13位元的PID，但在本技術中，在採用第2種PID對應方式的情況下，則是藉由送訊側的送訊裝置10進行管理，以使得由複數PLP所構成的1個服務內，PID不會重複。
(第2送訊側PID對應處理) 　　此處，參照圖27的流程圖，說明由送訊裝置10所執行的第2送訊側PID對應處理之流程。
於步驟S321中，調變部112，係將被輸入至此的TS封包加以處理，在其標頭的PID領域中，設定PID之際，係進行管理，以使得由複數PLP所構成的1個服務內，PID不會重複。
此處，例如，調變部112係在內建的記憶體中，記錄PID管理用的表格，一面參照該當表格，一面管理對象之服務內所被使用的PID，藉此以使得PID不會重複。
藉此，作為TS封包的標頭之PID領域內的PID領域資訊是含有：在送訊側之送訊裝置10中被管理成不會重複的PID。對如此所得之TS封包，實施調變處理等之必要的處理，其結果所得之播送訊號會被發送。
以上說明了第2送訊側PID對應處理之流程。
此外，於第2種PID對應方式中，由收訊裝置20所執行的處理，係和上述的第1種PID對應方式基本相同，因此省略其詳細說明，但在以下幾點係有不同。
亦即，於收訊裝置20的處理部212中，係藉由解多工器241，作為從TS封包的標頭之PID領域所得之PID領域資訊，會獲得在送訊側之送訊裝置10中被管理成不會重複的PID。藉此，解多工器241，係可按照PID所相應之PLP之序列之每一者，將TS封包予以輸出。
(2-3)第3種PID對應方式
在MPEG2-TS方式中，係於圖23所示的TS封包的標頭中，在PID領域中，配置13位元的PID，但在本技術中，在採用第3種PID對應方式的情況下，則是藉由收訊側的收訊裝置20(的解調部211)進行管理，以使得由複數PLP所構成的1個服務內，PID不會重複。
(解調部側PID對應處理) 　　此處，參照圖28的流程圖，說明被收訊裝置20所執行的解調部側PID對應處理之流程。
於步驟S331中，解調多工器233，係將被輸入至此的TS封包加以處理，在辨識其標頭的PID領域中所被設定的PID之際，係進行管理，以使得由複數PLP所構成的1個服務內，PID不會重複。
亦即，解調多工器233，係在由複數PLP所構成的1個服務內，若有PID重複，則置換成不重複的PID。此處，例如，解調多工器233係在內建的記憶體中，記錄PID管理用的表格，一面參照該當表格，一面管理處理對象之服務內所被使用的PID，藉此以使得PID不會重複。
以上說明了解調部側PID對應處理之流程。
此外，於第3種PID對應方式中，由處理部212所執行的處理，係和上述的第1種PID對應方式基本相同，因此省略其詳細說明，但在以下幾點係有不同。
亦即，於收訊裝置20的處理部212中，係藉由解多工器241，作為從傳輸封包的標頭之PID領域所得之PID領域資訊，會獲得在收訊側(的解調部211)被管理成不會重複的PID。藉此，解多工器241，係可按照PID所相應之PLP之序列之每一者，將TS封包予以輸出。
如以上所述，藉由在TS封包的標頭之PID領域中，配置作為PLP_ID之對映資訊的PID領域資訊，就可在收訊側，使用該當PID領域資訊，來識別TS封包所屬之PLP。
又，不需要將相當於PLP_ID的資訊，對映至其他領域(PID領域)，例如，不需要對ALP封包附加PLP_ID，因此，在收訊側的收訊裝置20中，作為解調元件的解調部211、和作為單晶片系統(SoC)的處理部212之間的單一介面(I/F)中的傳輸速率之上升，可被抑制。其結果為，可使收訊側的電路實作變得容易。
此外，上述的說明中，送訊側的PID之相關處理，是假設成例如，由被設置在送訊所側的(資料處理裝置的)調變部112(處理部)所執行來做說明，但送訊側的PID之相關處理，係亦可由被設置在播送台側的(資料處理裝置的)多工器111(處理部)來執行。
＜4.變形例＞
(對其他播送方式之適用) 　　在上述的說明中，作為數位播送的規格，是說明了被美國等所採用的方式也就是ATSC(尤其是ATSC3.0)，但本技術係亦可適用於被日本等所採用的方式也就是ISDB (Integrated Services Digital Broadcasting)、或被歐洲各國等所採用的方式也就是DVB(Digital Video Broadcasting)等。又，如上述，作為資料傳輸之方式，係不限於IP傳輸方式，例如，亦可適用MPEG2-TS方式等之其他方式。
又，作為數位播送之規格，係除了地上波播送以外，亦可適用於利用播送衛星(BS：Broadcasting Satellite)或通訊衛星(CS：Communications Satellite)等的衛星播送、或纜線電視(CATV)等之有線播送等之規格。
(對播送方式以外之方式的適用) 　　又，本技術，作為傳輸路，亦可適用於播送網以外之傳輸路，亦即例如：想定會利用網際網路或電話網等之通訊線路(通訊網)等而被規定的所定之規格(數位播送之規格以外之規格)等。此情況下，作為播送系統1(圖1)的傳輸路30，可利用網際網路或電話網等之通訊線路，送訊裝置10係可為被設置在網際網路上的伺服器。然後，該當通訊伺服器、與收訊裝置20，係透過傳輸路30(通訊線路)而進行雙向通訊。
(收訊側的其他構成) 　　此外，在上述的說明中雖然說明了，於收訊裝置20中，作為解調元件的解調部211、與作為單晶片系統(SoC)的處理部212之間，是藉由單一介面(I/F)而被連接的構成，但只要少於往解調部211的解調多工器233所被輸入的，對應於PLP的IP串流之序列之數量即可，介面(I/F)之數量係不限於1個，亦可為2個以上。
亦即，解調部211與處理部212之間的介面(I/F)之數量，係可設計成單一或少於PLP之個數的數量。又，例如，於收訊裝置20中，對1個解調部211，是設有複數個處理部212的情況下，則會設置複數個介面(I/F)。
＜5.電腦的構成＞
上述一連串處理，係可藉由硬體來執行，也可藉由軟體來執行。在以軟體來執行一連串之處理時，構成該軟體的程式，係可安裝至電腦。圖29係以程式來執行上述一連串處理的電腦的硬體之構成例的圖示。
於電腦1000中，CPU(Central Processing Unit)1001、ROM(Read Only Memory)1002、RAM(Random Access Memory)1003，係藉由匯流排1004而被彼此連接。在匯流排1004上係還連接有輸出入介面1005。輸出入介面1005上係連接有：輸入部1006、輸出部1007、記錄部1008、通訊部1009、及驅動機1010。
輸入部1006，係由鍵盤、滑鼠、麥克風等所成。輸出部1007係由顯示器、揚聲器等所成。記錄部1008，係由硬碟或非揮發性記憶體等所成。通訊部1009係由網路介面等所成。驅動機1010係驅動：磁碟、光碟、光磁碟、或半導體記憶體等之可移除式記錄媒體1011。
在如以上構成的電腦1000中，藉由CPU1001而例如將ROM1002或記錄部1008中所被記錄之程式，透過輸出入介面1005及匯流排1004，而載入至RAM1003裡並加以執行，就可進行上述一連串處理。
電腦1000(CPU1001)所執行的程式，係可記錄在例如套裝媒體等之可移除式記錄媒體1011中而提供。又，程式係可透過區域網路、網際網路、數位衛星播送這類有線或無線的傳輸媒體而提供。
在電腦1000中，程式係藉由將可移除式記錄媒體1011裝著至驅動機1010，就可透過輸出入介面1005，安裝至記錄部1008。又，程式係可透過有線或無線之傳輸媒體，以通訊部1009接收之，安裝至記錄部1008。除此以外，程式係可事前安裝在ROM1002或記錄部1008中。
此處，於本說明書中，電腦依照程式而進行之處理，係並不一定依照流程圖方式所記載之順序而時間序列性地進行。亦即，電腦依照程式所進行的處理，係包含可平行地或個別地執行之處理(例如平行處理或是物件所致之處理)。又，程式係可被1台電腦(處理器)所處理，也可被複數台電腦分散處理。
此外，本技術的實施形態係不限定於上述實施形態，在不脫離本技術主旨的範圍內可做各種變更。
又，本技術係可採取如下之構成。
(1) 　　一種收訊裝置，係 　　具備： 　　解調部，係將按照播送訊號中所含之複數PLP (Physical Layer Pipe)之每一者所獲得之封包予以解調；和 　　處理部，係將已被前記解調部所解調之前記封包，加以處理； 　　前記解調部與前記處理部，係透過單一或少於PLP之個數的介面而被連接； 　　前記解調部，係在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊； 　　前記處理部，係基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP。 　　(2) 　　如前記(1)所記載之收訊裝置，其中， 　　前記解調部，係對從同一PLP連續所得之封包，將前記識別資訊只附加1次。 　　(3) 　　如前記(2)所記載之收訊裝置，其中， 　　前記解調部，係在從同一PLP連續所得之封包之中，對開頭之封包，附加前記識別資訊； 　　前記處理部，係將從已被附加有前記識別資訊的封包起，至下個有被附加前記識別資訊之封包的前1個封包為止的封包群，視為隸屬於同一PLP的封包而加以處理。 　　(4) 　　如前記(1)所記載之收訊裝置，其中， 　　前記封包係可分割或結合； 　　前記解調部，係對已被分割之分割封包、或由複數封包所結合成的結合封包，附加前記識別資訊。 　　(5) 　　如前記(4)所記載之收訊裝置，其中， 　　前記分割封包係為，ATSC(Advanced Television Systems Committee)3.0中所被規定之分段封包或串接封包。 　　(6) 　　如前記(1)至(5)之任一項所記載之收訊裝置，其中， 　　前記封包係儲存有，含有UDP(User Datagram Protocol)封包的IP(Internet Protocol)封包。 　　(7) 　　如前記(6)所記載之收訊裝置，其中， 　　前記封包係為，ATSC3.0中所被規定之ALP(ATSC Link-Layer Protocol)封包。 　　(8) 　　如前記(1)至(7)之任一項所記載之收訊裝置，其中， 　　前記識別資訊係為PLP_ID。 　　(9) 　　如前記(1)至(8)之任一項所記載之收訊裝置，其中， 　　前記解調部，係為解調元件； 　　前記處理部，係為單晶片系統(SoC：System on Chip)。 　　(10) 　　一種資料處理方法，係為收訊裝置之資料處理方法，該收訊裝置係具有： 　　解調部，係將按照播送訊號中所含之複數PLP之每一者所獲得之封包予以解調；和 　　處理部，係將已被前記解調部所解調之前記封包，加以處理； 　　前記解調部與前記處理部，係透過單一或少於PLP之個數的介面而被連接； 　　其中，該資料處理方法係含有以下步驟： 　　由前記解調部，在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊； 　　由前記處理部，基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP。
1‧‧‧播送系統
10‧‧‧送訊裝置
20‧‧‧收訊裝置
30‧‧‧傳輸路
111‧‧‧多工器
112‧‧‧調變部
211‧‧‧解調部
212‧‧‧處理部
231‧‧‧訊框處理部
232-1乃至232-4‧‧‧FEC處理部
233‧‧‧解調多工器
241‧‧‧解多工器
242-1乃至242-4‧‧‧封裝化解除部
1000‧‧‧電腦
1001‧‧‧CPU
1002‧‧‧ROM
1003‧‧‧RAM
1004‧‧‧匯流排
1005‧‧‧輸出入介面
1006‧‧‧輸入部
1007‧‧‧輸出部
1008‧‧‧記錄部
1009‧‧‧通訊部
1010‧‧‧驅動機
1011‧‧‧可移除式記錄媒體
[圖1] 適用了本技術的播送系統之構成例的區塊圖。 　　[圖2] 送訊裝置之構成例的區塊圖。 　　[圖3] 收訊裝置之構成例的區塊圖。 　　[圖4] 透過單一介面而被輸出的ALP封包的輸出時序之例子的圖示。 　　[圖5] 實體層訊框的結構之例子的圖示。 　　[圖6] ALP封包的結構之例子的圖示。 　　[圖7] 對透過單一介面而被輸出的ALP封包的，PLP_ID的附加時序之例子的圖示。 　　[圖8] 解調部側ALP封包輸出處理之流程的說明用流程圖。 　　[圖9] 處理部側ALP封包輸入處理之流程的說明用流程圖。 　　[圖10] ALP封包的結構之例子的圖示。 　　[圖11] ALP標頭之語法之例子的圖示。 　　[圖12] 對透過單一介面而被輸出的ALP封包的，PLP_ID的附加時序之例子的圖示。 　　[圖13] IP資料流之構成之例子的圖示。 　　[圖14] IR封包的結構之例子的圖示。 　　[圖15] IR-DYN封包的結構之例子的圖示。 　　[圖16] UO-0封包的結構之例子的圖示。 　　[圖17] Add-CID octet的結構之例子的圖示。 　　[圖18] 第1送訊側CID對應處理之流程的說明用流程圖。 　　[圖19] 處理部側CID對應處理之流程的說明用流程圖。 　　[圖20] 第2送訊側CID對應處理之流程的說明用流程圖。 　　[圖21] 第3送訊側CID對應處理之流程的說明用流程圖。 　　[圖22] 解調部側CID對應處理之流程的說明用流程圖。 　　[圖23] TS封包之語法之例子的圖示。 　　[圖24] PID的結構之例子的圖示。 　　[圖25] 第1送訊側PID對應處理之流程的說明用流程圖。 　　[圖26] 處理部側PID對應處理之流程的說明用流程圖。 　　[圖27] 第2送訊側PID對應處理之流程的說明用流程圖。 　　[圖28] 解調部側PID對應處理之流程的說明用流程圖。 　　[圖29] 電腦之構成例的圖示。

Claims (9)

  1. 一種收訊裝置，係具備：解調部，係將按照播送訊號中所含之複數PLP(Physical Layer Pipe)之每一者所獲得之封包予以解調；和處理部，係將已被前記解調部所解調之前記封包，加以處理；前記解調部與前記處理部，係透過單一或少於PLP之個數的介面而被連接；前記解調部，係在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊；前記處理部，係基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP；前記解調部，係對從同一PLP連續所得之封包，將前記識別資訊只附加1次。
  2. 如請求項1所記載之收訊裝置，其中，前記解調部，係在從同一PLP連續所得之封包之中，對開頭之封包，附加前記識別資訊；前記處理部，係將從已被附加有前記識別資訊的封包起，至下個有被附加前記識別資訊之封包的前1個封包為止的封包群，視為隸屬於同一PLP的封包而加以處理。
  3. 如請求項1所記載之收訊裝置，其中，前記封包係可分割或結合；前記解調部，係對已被分割之分割封包、或由複數封包所結合成的結合封包，附加前記識別資訊。
  4. 如請求項3所記載之收訊裝置，其中，前記分割封包係為，ATSC(Advanced Television Systems Committee)3.0中所被規定之分段封包或串接封包。
  5. 如請求項1所記載之收訊裝置，其中，前記封包係儲存有，含有UDP(User Datagram Protocol)封包的IP(Internet Protocol)封包。
  6. 如請求項5所記載之收訊裝置，其中，前記封包係為，ATSC3.0中所被規定之ALP(ATSC Link-Layer Protocol)封包。
  7. 如請求項1所記載之收訊裝置，其中，前記識別資訊係為PLP_ID。
  8. 如請求項1所記載之收訊裝置，其中，前記解調部，係為解調元件；前記處理部，係為單晶片系統(SoC：System on Chip)。
  9. 一種資料處理方法，係為收訊裝置之資料處理方法，該收訊裝置係具有：解調部，係將按照播送訊號中所含之複數PLP之每一者所獲得之封包予以解調；和處理部，係將已被前記解調部所解調之前記封包，加以處理；前記解調部與前記處理部，係透過單一或少於PLP之個數的介面而被連接；其中，該資料處理方法係含有以下步驟：由前記解調部，在按照前記PLP之每一者所得之封包之中，對特定之封包，附加可用來識別前記封包所屬之PLP的識別資訊；由前記處理部，基於從前記特定之封包所得之前記識別資訊，來識別從前記解調部透過單一或少於PLP之個數的介面而被輸入的前記封包所隸屬的PLP；前記解調部，係對從同一PLP連續所得之封包，將前記識別資訊只附加1次。
TW107106779A 2017-03-14 2018-03-01 收訊裝置、及資料處理方法 TWI661728B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2017049173 2017-03-14
JP2017-049173 2017-03-14

Publications (2)

Publication Number Publication Date
TW201836347A TW201836347A (zh) 2018-10-01
TWI661728B true TWI661728B (zh) 2019-06-01

Family

ID=63523275

Family Applications (1)

Application Number Title Priority Date Filing Date
TW107106779A TWI661728B (zh) 2017-03-14 2018-03-01 收訊裝置、及資料處理方法

Country Status (7)

Country Link
US (3) US10812207B2 (zh)
EP (1) EP3598768A4 (zh)
JP (1) JP7139311B2 (zh)
KR (1) KR102424932B1 (zh)
CN (1) CN110383850B (zh)
TW (1) TWI661728B (zh)
WO (1) WO2018168456A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111541518A (zh) * 2020-04-17 2020-08-14 展讯通信（上海）有限公司 一种串行总线的数据传输方法及通信装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106170966A (zh) * 2015-02-17 2016-11-30 索尼公司 传输设备、传输方法、接收设备以及接收方法
WO2017039272A1 (en) * 2015-08-31 2017-03-09 Samsung Electronics Co., Ltd. Apparatus and method for transmitting and receiving signal in multimedia system
TW201731273A (zh) * 2016-01-13 2017-09-01 Sony Corp 資料處理裝置、及資料處理方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000134168A (ja) 1998-10-27 2000-05-12 Toshiba Corp デジタル放送受信後のデータ出力方式
US6864151B2 (en) * 2003-07-09 2005-03-08 Infineon Technologies Ag Method of forming shallow trench isolation using deep trench isolation
KR101341519B1 (ko) 2007-07-30 2013-12-16 엘지전자 주식회사 방송 수신기 및 데이터 처리 방법
JP5641090B2 (ja) * 2013-03-14 2014-12-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
CN106031178A (zh) * 2014-01-21 2016-10-12 Lg电子株式会社 广播发送装置及其操作方法、和广播接收装置及其操作方法
EP3136670A4 (en) * 2014-04-21 2018-01-24 LG Electronics Inc. Broadcasting signal transmission apparatus, broadcasting signal reception apparatus, broadcasting signal transmission method, and broadcasting reception method
WO2016111560A1 (en) * 2015-01-07 2016-07-14 Samsung Electronics Co., Ltd. Transmitting apparatus and receiving apparatus and signal processing method thereof
US10848798B2 (en) * 2016-06-01 2020-11-24 Lg Electronics Inc. Broadcast signal transmission and reception device and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106170966A (zh) * 2015-02-17 2016-11-30 索尼公司 传输设备、传输方法、接收设备以及接收方法
WO2017039272A1 (en) * 2015-08-31 2017-03-09 Samsung Electronics Co., Ltd. Apparatus and method for transmitting and receiving signal in multimedia system
TW201731273A (zh) * 2016-01-13 2017-09-01 Sony Corp 資料處理裝置、及資料處理方法

Also Published As

Publication number Publication date
KR20190122700A (ko) 2019-10-30
EP3598768A4 (en) 2020-03-11
TW201836347A (zh) 2018-10-01
JPWO2018168456A1 (ja) 2020-01-16
US20200412467A1 (en) 2020-12-31
EP3598768A1 (en) 2020-01-22
US11838099B2 (en) 2023-12-05
JP7139311B2 (ja) 2022-09-20
US10812207B2 (en) 2020-10-20
US20200028604A1 (en) 2020-01-23
CN110383850A (zh) 2019-10-25
WO2018168456A1 (ja) 2018-09-20
US11336381B2 (en) 2022-05-17
CN110383850B (zh) 2022-05-17
US20220329334A1 (en) 2022-10-13
KR102424932B1 (ko) 2022-07-25

Similar Documents

Publication Publication Date Title
CN107079028B (zh) 发送装置和接收装置及其信号处理方法
KR102386821B1 (ko) 방송 시스템에서 시스템 시간 정보를 송수신하는 기법
US20240137603A1 (en) Transmission apparatus, reception apparatus, and data processing method
TWI661728B (zh) 收訊裝置、及資料處理方法
KR102012478B1 (ko) 송신 장치, 수신 장치 및 그 제어 방법
KR102062897B1 (ko) 송신 장치, 수신 장치 및 그 신호 처리 방법
KR102404241B1 (ko) 송신 장치 및 그 송신 방법
KR20160140359A (ko) 송신 장치, 수신 장치 및 그 제어 방법
CN111447243B (zh) 发送装置和接收装置及其信号处理方法
KR20200003769A (ko) 송신 장치, 수신 장치 및 그 신호 처리 방법

Legal Events

Date Code Title Description
MM4A Annulment or lapse of patent due to non-payment of fees