WO2016136489A1

WO2016136489A1 - Reception apparatus, reception method, transmission apparatus and transmission method

Info

Publication number: WO2016136489A1
Application number: PCT/JP2016/054070
Authority: WO
Inventors: 山岸　靖明
Original assignee: ソニー株式会社
Priority date: 2015-02-27
Filing date: 2016-02-12
Publication date: 2016-09-01
Also published as: MX358332B; MX2016013763A; US10264296B2; JPWO2016136489A1; US20170041643A1; CN106233703A; CA2945605A1; EP3855771A1; EP3264729B1; EP3264729A4; KR20170122640A; EP3264729A1; CN106233703B; US20190191190A1

Abstract

This technique relates to a reception apparatus, a reception method, a transmission apparatus and a transmission method that enable bearers transferred by use of a plurality of transfer systems to be appropriately selected. The reception apparatus acquires control information including information that is used for acquiring data transferred by a session using a first transfer system in a first layer in a protocol stack of an IP transfer system and that is used for identifying a bearer transferring the data by use of a second transfer system in a second layer lower than the first layer, and the reception apparatus controls, on the basis of the control information, the operations of the components that acquire the data transferred on the bearer. This technique can be applied to, for example, an ATSC-3.0-compliant television receiver.

Description

Receiving device, receiving method, transmitting device, and transmitting method

The present technology relates to a reception device, a reception method, a transmission device, and a transmission method, and in particular, a reception device, a reception method, a transmission device, and a transmission device that can appropriately select bearers to be transmitted in a plurality of transmission schemes. And a transmission method.

In recent years, the mainstream streaming service on the Internet has become the so-called OTT-V (Over The Top Video). MPEG-DASH (Dynamic-Adaptive-Streaming-over-HTTP) is beginning to spread as a basic technology of OTT-V (see, for example, Non-Patent Document 1).

MPEG-DASH is based on a streaming protocol based on HTTP (Hypertext Transfer Protocol), but for content that is suitable for simultaneous broadcast delivery, multicast (MC: Multicast) or broadcast (BC: Broadcast) A method of reducing the load of network resources by using a bearer together can be considered.

By the way, there is a demand for a technique for appropriately selecting a bearer to be transmitted using different transmission methods when content data suitable for simultaneous broadcast distribution is transmitted using a plurality of transmission methods.

The present technology has been made in view of such a situation, and makes it possible to appropriately select a bearer transmitted by a plurality of transmission methods.

The receiving device according to the first aspect of the present technology is information for acquiring data transmitted in a session using the first transmission method in a first layer in a protocol stack of an IP (Internet Protocol) transmission method, Based on the control information, an acquisition unit that acquires control information including information for identifying a bearer that transmits the data by a second transmission scheme in a second layer lower than the first layer, It is a receiving apparatus provided with the control part which controls operation | movement of each part which acquires the said data transmitted on the said bearer.

The receiving device according to the first aspect of the present technology may be an independent device, or may be an internal block constituting one device. The reception method according to the first aspect of the present technology is a reception method corresponding to the reception device according to the first aspect of the present technology described above.

The receiving device and the receiving method according to the first aspect of the present technology are information for acquiring data transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method. Control information including information for identifying the bearer transmitting the data by the second transmission scheme in the second layer lower than the first layer is acquired, and based on the control information, The operation of each unit that acquires the data transmitted on the bearer is controlled.

A transmission device according to a second aspect of the present technology is information for acquiring data transmitted in a session according to a first transmission scheme in a first layer in a protocol stack of an IP transmission scheme, Included in the control information together with the control information, a generation unit that generates control information including information for identifying the bearer that transmits the data by the second transmission scheme in the second layer lower than the layer A transmission unit that transmits the data by the bearer identified by the information.

The transmission device according to the second aspect of the present technology may be an independent device, or may be an internal block constituting one device. A transmission method according to the second aspect of the present technology is a transmission method corresponding to the transmission device according to the second aspect of the present technology described above.

In the transmission device and the transmission method according to the second aspect of the present technology, information for acquiring data transmitted in a session using the first transmission scheme in the first layer in the protocol stack of the IP transmission scheme. Control information including information for identifying a bearer transmitting the data by the second transmission method is generated in a second layer lower than the first layer, and the control information is generated together with the control information. The data is transmitted by the bearer identified by the information included in.

According to the first aspect and the second aspect of the present technology, it is possible to appropriately select a bearer transmitted by a plurality of transmission methods.

It should be noted that the effects described here are not necessarily limited, and may be any of the effects described in the present disclosure.

It is a figure which shows the protocol stack of 3GPP- (e) MBMS. It is a figure which shows the protocol stack of ATSC3.0. It is a figure which shows the structure of ROUTE / FLUTE. It is a figure which shows the detailed structure of FLUTE. It is a figure which shows the detailed structure of ROUTE. It is a figure which shows the example of the fragmentation in ROUTE. It is a figure which shows the decomposition | disassembly by a ROUTE header. It is a figure which shows the example of the fragment transfer sequence by ROUTE. It is a figure which shows the protocol stack of 3GPP- (e) MBMS assumed in the future. It is a figure which shows the structural example of a transmission system. It is a figure which shows the structure of a ROUTE session. It is a figure which shows the structure of LSID. It is a figure which shows the detailed content of the component of LSID. It is a figure explaining the flow of data acquisition using LSID. It is a figure explaining the flow of data acquisition using extended LSID. It is a figure which shows the other structure of extended LSID. It is a figure explaining the flow of the data acquisition using extended LSID with which the transport bearer ID was described. It is a figure which shows the 1st structure of extended LSID. It is a figure which shows the specific description example of the 1st structure of extended LSID. It is a figure which shows the 2nd structure of extended LSID. It is a figure which shows the specific description example of the 2nd structure of extended LSID. It is a figure which shows the specific operation example of the receiving side system which processes the broadcast stream transmitted from a transmitting side system. It is a figure which shows the structural example of a transmission side system. It is a figure which shows the structural example of a receiving side system. It is a flowchart explaining the flow of a process of a transmission side system. It is a flowchart explaining the flow of a process of a receiving side system. It is a figure which shows the structural example of a computer.

Hereinafter, embodiments of the present technology will be described with reference to the drawings. The description will be made in the following order.

1. 1. Outline of digital broadcasting by IP transmission method 2. System configuration Extended LSID using this technology
(1) Outline of LSID (2) Extended LSID
(3) Transport bearer identification by extended LSID 4. Specific operation example of system 5. Configuration of each device of the system 6. Flow of processing executed by each device of the system Modification 8 Computer configuration

<1. Overview of digital broadcasting using IP transmission system>

In the digital broadcasting standards of each country, MPEG2-TS (Moving Picture Experts Group Phase 2-Transport Stream) is adopted as the transmission method, but in the future IP (Internet Protocol) packets used in the field of communication will be used. It is assumed that more advanced services will be provided by introducing an IP transmission method using digital video for digital broadcasting. In particular, ATSC (Advanced Television Systems Committee) 3.0, the next-generation broadcasting standard in the United States that is currently being developed, is expected to adopt digital broadcasting using the IP transmission method.

In the following, the outline of digital broadcasting using the IP transmission method will be described.Here, first, 3GPP- (e) MBMS (Multimedia Broadcast Multicast) formulated by 3GPP (Third Generation Partnership Project), a standardization project for mobile communication systems Outline of Service) is explained.

(3GPP- (e) MBMS protocol stack)
FIG. 1 is a diagram illustrating a protocol stack of 3GPP- (e) MBMS.

In FIG. 1, the lowest hierarchy is a physical layer. In 3GPP- (e) MBMS, in the case of transmission using the transmission method on the right side in the figure, the physical layer uses either one-way MBMS or two-way ptp Bearer (s).

The upper layer adjacent to the physical layer is the IP layer. The upper layer adjacent to the IP layer is a UDP / TCP layer. That is, when MBMS is used as the physical layer, IP multicast is used in the IP layer, and UDP (User Datagram Protocol) is used in the UDP / TCP layer. On the other hand, when using ptp Bearer (s) as the physical layer, IP unicast is used in the IP layer, and TCP (Transmission Control Protocol) is used in the UDP / TCP layer.

The upper layers adjacent to the UDP / TCP layer are FEC, HTTP (S), and FLUTE. FLUTE (File Delivery over Unidirectional Transport) is a protocol for file transfer in multicast. Note that FEC (Forward Error Correction) is applied to FLUTE. The detailed contents of FLUTE will be described later with reference to FIG.

The upper layers adjacent to FLUTE are 3GP-DASH, Download 3GPP file format, etc, ptm File repair, Service Announcement & Metadata. Further, the upper hierarchy adjacent to ptm File Repair is set to Associated Delivery Procedures.

The upper layer adjacent to 3GP-DASH (Dynamic Adaptive Streaming over HTTP) is stream data such as audio and video. That is, stream data such as audio and video constituting the content can be transmitted in a FLUTE session in units of media segments (Media Segment) conforming to the ISO BMFF (Base Media File Format) standard.

In addition, for example, USD (User Service Description) and MPD (Media Presentation Description) can be arranged in the Service Announcement & Metadata as control information of stream data transmitted in the FLUTE session. Therefore, control information such as USD and MPD can also be transmitted in the FLUTE session.

In this way, 3GPP- (e) MBMS specifies a file download protocol for FLUTE sessions of files based on the 3GPP file format (ISOFFBMFF file, MP4 file). Fragmented MP4 file sequence and MPD conforming to the MPEG-DASH standard can be transmitted. MPD is referenced from USD. Fragmented MP4 means a fragmented MP4 file.

Note that the upper layer of HTTP (S), which is the upper layer adjacent to the UDP / TCP layer, is 3GP-DASH stream data. That is, 3GP-DASH stream data can also be transmitted using HTTP (S). In addition, the upper layers of the FEC that are upper layers adjacent to the UDP / TCP layer are RTP / RTCP and MIKEY. The upper layer of RTP / RTCP is RTP PayloadFormats, and the upper layer is stream data. That is, stream data can be transmitted through an RTP (Real-time Transport-Protocol) session. The upper layer of MIKEY is Key Distribution (MTK), and the upper layer is MBMS Security.

On the other hand, in the case of transmission using the transmission method on the left side in the figure, the physical layer uses only bidirectional ptpptBearer. The upper layer adjacent to the physical layer is an IP layer. The upper layer adjacent to the IP layer is the TCP layer, and the upper layer adjacent to the TCP layer is the HTTP (S) layer. That is, a protocol stack that operates on a network such as the Internet is implemented by these layers.

The upper layers adjacent to the HTTP (S) layer are Service Announcement & Metadata, ptm File Repair, Reception Reporting, Registration. In Service Announcement & Metadata, USD and MPD can be arranged as control information of stream data transmitted in the FLUTE session using the transmission method on the right side in the figure. Therefore, for example, control information such as USD and MPD can be provided by a server on the Internet.

Note that the upper hierarchy adjacent to ptm File Repair and Reception Reporting is associated Delivery Procedures. The upper layer adjacent to Registration is MBMSMBSecurity. Furthermore, the upper layer of the UDP layer, which is the upper layer adjacent to the IP layer, is MIKEY. The upper layer of MIKEY is Key Distribution (MTK), and the upper layer is MBMS Security. In addition, for example, an application (Application (s)) may be transmitted using a FLUTE session using the transmission method on the right side in the figure or a TCP / IP protocol using the transmission method on the left side in the figure. it can.

(ATSC3.0 protocol stack)
FIG. 2 is a diagram showing a protocol stack of ATSC 3.0.

In FIG. 2, the lowest hierarchy is a physical layer. In digital broadcasting of IP transmission system such as ATSC3.0, not only transmission using broadcasting, but some data may be transmitted using communication. When using broadcasting, the physical layer ( Broadcast PHY) corresponds to the frequency band of the broadcast wave allocated for the service (channel).

The upper layer of the physical layer (Broadcast PHY) is the IP layer (IP multicast). The IP layer corresponds to IP (Internet Protocol) in the TCP / IP protocol stack, and an IP packet is specified by an IP address. The upper layer adjacent to the IP layer is a UDP layer, and the upper layer is a ROUTE (Real-time Object Delivery over Unidirectional Transport). ROUTE is a protocol for file transfer in multicast, and is an extension of FLUTE. The detailed contents of ROUTE will be described later with reference to FIG.

Among the upper layers adjacent to ROUTE, some layers are ESG (Electronic Service Guide) service and NRT content (NRT content), and the ESG service and NRT content files are transmitted by the ROUTE session. The ESG service is an electronic service guide (program information). The NRT content is content transmitted by NRT (Non Real Time) broadcasting, and is played back after being temporarily stored in the storage of the receiver. Note that the NRT content is an example of content, and a file of another content may be transmitted by the ROUTE session.

Of the upper layers adjacent to ROUTE, the layers other than the above-mentioned layers are DASH (ISOASHBMFF). The upper layer adjacent to DASH (ISO （BMFF) is stream data of components such as video (Video), audio (Audio), and subtitles (CC: Closed Caption). That is, stream data of components such as audio, video, and subtitles constituting the content is transmitted by the ROUTE session in units of media segments in accordance with the ISO BMFF standard.

Also, the upper layer adjacent to the physical layer (Broadcast PHY) and the layer straddling the upper layer adjacent to ROUTE are used as signaling information (Singaling). For example, the signaling information includes LLS (Link (Layler Signaling) signaling information and SLS (Service Level Singaling) signaling information.

LLS signaling information is low-layer signaling information that does not depend on services. For example, the LLS signaling information includes metadata such as FIT (Fast Information Table), EAD (Emergency Alerting Description), and RRD (Region Information Rating Description). The FIT includes information indicating the configuration of a stream and a service in a broadcast network, such as information necessary for channel selection. EAD contains information about emergency alerts. The RRD contains information about the rating.

SLS signaling information is signaling information for each service. For example, the SLS signaling information includes metadata such as LSID (LCT Session Instance Description) in addition to the USD and MPD described above. LSID is ROUTE protocol control information (control metafile). The detailed contents of ROUTE will be described later with reference to FIG.

On the other hand, when using communication, the upper layer of the physical layer (Broadband PHY) is the IP layer (IP unicast). The upper layer adjacent to the IP layer is the TCP layer, and the upper layer adjacent to the TCP layer is the HTTP (S) layer. That is, a protocol stack that operates on a network such as the Internet is implemented by these layers.

Thus, the receiver can communicate with a server on the Internet using the TCP / IP protocol and receive ESG service, signaling information, NRT content, and the like. Further, the receiver can receive stream data such as audio and video that are adaptively streamed and distributed from a server on the Internet. This streaming distribution conforms to the MPEG-DASH standard.

Also, for example, applications can be transmitted using a broadcast ROUTE session or communication TCP / IP protocol. This application can be written in a markup language such as HTML5 (HyperText Markup Language 5).

As mentioned above, part of the ATSC3.0 protocol stack adopts a protocol stack that supports 3GPP-MBMS. As a result, audio and video stream data constituting the content can be transmitted in units of media segments conforming to the ISO FFFF standard. In addition, whether signaling information such as SLS signaling information is transmitted by broadcasting or communication, the layer excluding the physical layer (and data link layer) that is a lower layer than the IP layer, that is, the IP layer In higher layers, it is possible to make the protocol common, so that the burden of mounting and processing can be reduced in the receiver and the like.

(ROUTE / FLUTE structure)
FIG. 3 is a diagram showing the structure of FLUTE in the 3GPP- (e) MBMS protocol stack of FIG. 1 and ROUTE in the ATSC 3.0 protocol stack of FIG.

FLUTE is composed of a scalable file object multicast protocol called ALC (Asynchronous Layered Coding), specifically a combination of its building blocks, LCT (Layered Coding Transport) and FEC (Forward Error Correction) components. FIG. 4 shows the detailed structure of FLUTE.

Here, ALC is a protocol suitable for multicast transmission of arbitrary binary files in one direction. In other words, ALC was developed as a highly reliable asynchronous one-to-many broadcast type protocol, but uses LCT and FEC, and applies the FEC to the target file and stores it in the LCT packet. When transferring on IP multicast, it is stored in UDP packet and IP packet.

A transport session in FLUTE is identified by a unique TSI (Transport Session Identifier) in the scope of the source IP address. In FLUTE, the FEC method can be changed for each transport session or for each file. Also, FLUTE introduces transfer control information in XML (Extensible Markup Language) format called FDT (File Delivery Table) transferred for each transport session.

Describe the basic attributes and transfer control parameters of the target file in the FDT file transferred in the same transport session as the FEC encoding symbol stored in the LCT packet. The FDT defines the mapping between the identifier of the target file and the LCT packet sequence that stores the corresponding FEC encoding symbol sequence. Furthermore, the MIME type and size of each file, the transfer encoding method, the message digest, and the FEC Parameters necessary for decoding can be stored. Note that FEC can also be applied to the FDT itself, and its own FEC parameters and the like are transmitted separately in the LCT layer.

By the way, ROUTE is an extension of FLUTE, but the difference can mainly include object bundles and media-aware fragmentation. FIG. 5 shows the detailed structure of ROUTE.

The feature of object bundle in ROUTE is that a stream of video and audio consisting of source blocks of different sizes is bundled and configured as one super object, and an FEC repair stream is generated based on that, a source stream, It is in the place of supporting the repair stream related notification at the protocol level.

Generally, an audio stream or the like has a small source object size compared to a video stream because the data amount per unit time (data object) is small. When a repair symbol is generated for each stream using the same FEC method for streams having different source object sizes, the sensitivity to errors varies depending on the size of the source object.

In ROUTE, a source block is cut out from a plurality of source streams with different rates to form a super object, and a repair stream can be configured by FEC repair symbols generated based on the super object. That is, a repair stream is generated across different types of source streams. Here, a source stream composed of source symbols, a repair stream composed of repair symbols, and another LCT session in the ROUTE session can be transferred.

Information (control information) on how to construct a super object and generate an FEC stream from source blocks cut out from multiple source streams is described in LSID (LCT Session Instance Description). On the receiver side, based on the information described in the LSID, it is possible to restore the super object from the LCT packet sequence transmitted in the ROUTE session and extract the target file.

Generally, a broadcast stream is a model in which all the streams constituting a service are multiplexed and transmitted on the transmitter side, and streams necessary for the broadcast stream are selected on the receiver side. Therefore, it is possible to apply a processing model in which a super-object consisting of all the streams constituting the service is configured on the transmitter side, the super-object is restored on the receiver side, and then the necessary streams are selected. In use cases, the FEC configuration method realized by ROUTE is effective.

Note that, as shown in FIG. 6, ROUTE enables media-aware fragmentation. The example of FIG. 6 illustrates fragmentation when the DASH segment is an IndexedIndexSelf-Initialization segment.

In FIG. 6, the segment metadata part is divided into pckt0, which is the first delivery object, and the first sample 1 is stored in pckt1. In order to indicate the boundary to be divided, the URL (Uniform Resource Locator) of each delivery object is described in the part corresponding to the FDT corresponding to the LSID. This URL format can be configured in the form of a segment file URL and byte range format, or in the form of a segment file URL and sub-segment number format. When the subsegment number is “0”, it is a metadata part.

As the delivery object format, there are two types: a case where the object itself is stored as “file mode” and a format where an HTTP entity header is added as “entity mode”. These modes are the source of LSID. Described as a stream attribute. The HTTP entity header can store the URL and byte range of the object, and can also include attributes described in the conventional FDT.

In FLUTE, when dividing the target file into source blocks, a predetermined algorithm was applied, and mechanical division was performed without being aware of the processing boundary in the application, but in ROUTE, It is possible to divide the source block at a free boundary from the viewpoint of the application. FIG. 7 shows an example of storing a source delivery object in a transport packet. When the source delivery object needs to be divided when stored in the payload of the lower LCT packet, a ROUTE header is added so that the offset in the delivery object can be specified.

FIG. 8 shows how data is transferred in units of source delivery objects from the ROUTE server (ROUTEROSender) to the ROUTE client (ROUTE ソース Receiver). In general, it is normal to transfer the delivery objects in order, but in order to improve the experience speed at the time of channel switching, the delivery objects in which metadata such as SLS signaling information is stored are retransmitted more frequently. It is also possible.

In the above, ROUTE, which is an extension of FLUTE, has been described, but in the above-described current 3GPP- (e) MBMS protocol stack (FIG. 1), ROUTE will be specified in the future instead of or together with FLUTE. Is assumed (FIG. 9). In the following description, 3GPP- (e) MBMS is described as 3GPP-MBMS.

<2. System configuration>

FIG. 10 is a diagram illustrating a configuration of a transmission system to which the present technology is applied.

In FIG. 10, the transmission system 1 includes a transmission side system 10 and a reception side system 20. In the transmission system 1, data transmitted from the transmission side system 10 is received by the reception side system 20 via the transmission path 80 or the transmission path 90.

The sending system 10 corresponds to a predetermined standard such as ATSC3.0 or 3GPP-MBMS. The transmission side system 10 includes a data server 10A, a ROUTE server 10B, an ATSC broadcast server 10C, and a 3GPPMBMS server 10D.

The data server 10A is a server that manages data of content distributed from the transmission side system 10 to the reception side system 20 (for example, content suitable for simultaneous broadcast distribution). The data server 10A supplies content data to the ROUTE server 10B.

The ROUTE server 10B is a server that performs processing for transmitting content data supplied from the data server 10A in a ROUTE session.

The ROUTE server 10B generates an extended LSID based on information supplied from the ATSC broadcast server 10C or the 3GPPMBMS server 10D and supplies the extended LSID to the ATSC broadcast server 10C or the 3GPPMBMS server 10D. However, the extended LSID is an extension of the LSID, and the detailed contents thereof will be described later with reference to FIG.

Further, the ROUTE server 10B processes the content data supplied from the data server 10A to generate content data transmitted in the ROUTE session (hereinafter also referred to as ROUTE data), and the ATSC broadcast server 10C or 3GPPMBMS server. Supply to 10D.

The ATSC broadcast server 10C is a server for transmitting the ROUTE data from the ROUTE server 10B using a transport bearer compatible with ATSC 3.0.

The ATSC broadcast server 10C transmits the extended LSID supplied from the ROUTE server 10B to the receiving system 20 (ATSC broadcast client 20C) via the transmission path 80. Further, the ATSC broadcast server 10C performs processing for transmitting the ROUTE data supplied from the ROUTE server 10B on the ATSC3.0 transport bearer, and data obtained thereby (hereinafter also referred to as bearer data). ) To the receiving system 20 (ATSC broadcast client 20C) via the transmission path 80 (broadcast delivery).

The 3GPPMBMS server 10D is a server for transmitting the ROUTE data from the ROUTE server 10B using a transport bearer compatible with 3GPP-MBMS.

The 3GPPMBMS server 10D transmits the extended LSID supplied from the ROUTE server 10B to the receiving system 20 (3GPPMBMS client 20D) via the transmission path 90. Further, the 3GPPMBMS server 10D performs processing for transmitting the ROUTE data supplied from the ROUTE server 10B on the 3GPP-MBMS transport bearer, and transmits the bearer data obtained thereby via the transmission path 90. To the receiving side system 20 (3GPPMBMS client 20D).

The receiving side system 20 corresponds to a predetermined standard such as ATSC3.0 or 3GPP-MBMS. The receiving side system 20 includes a data client 20A, a ROUTE client 20B, an ATSC broadcast client 20C, and a 3GPPMBMS client 20D.

The 3GPPMBMS client 20D is a client for receiving a transport bearer corresponding to 3GPP-MBMS transmitted from the transmission side system 10.

The 3GPPMBMS client 20D receives the extended LSID transmitted from the 3GPPMBMS server 10D via the transmission path 90 and supplies it to the ROUTE client 20B. Further, the 3GPPMBMS client 20D receives and processes bearer data transmitted (broadcast broadcast) from the transmission side system 10 (3GPPMBMS server 10D) via the transmission path 90, and supplies it to the ROUTE client 20B.

The ATSC broadcast client 20C is a client for receiving a transport bearer corresponding to ATSC 3.0 transmitted from the transmission side system 10.

The ATSC broadcast client 20C receives the extended LSID transmitted from the ATSC broadcast server 10C via the transmission path 80 and supplies it to the ROUTE client 20B. Further, the ATSC broadcast client 20C receives and processes bearer data transmitted (broadcast delivery) from the transmission side system 10 (ATSC broadcast server 10C) via the transmission path 80, and supplies it to the ROUTE client 20B. .

The ROUTE client 20B is a client for processing ROUTE data transmitted on the ATSC3.0 or 3GPP-MBMS transport bearer.

The ROUTE client 20B acquires the ROUTE data transmitted on the ATSC3.0 or 3GPP-MBMS transport bearer (bearer data) based on the extended LSID supplied from the ATSC broadcast client 20C or the 3GPPMBMS client 20D. Supply to client 20A.

The data client 20A is a client for reproducing content data distributed (broadcast distribution) from the transmission side system 10 to the reception side system 20. Based on the ROUTE data supplied from the ROUTE client 20B, the data client 20A reproduces data of content (for example, content suitable for simultaneous broadcast delivery) and outputs the video and audio.

In FIG. 10, an ATSC broadcast server 10C and ATSC broadcast client 20C compatible with ATSC 3.0, a 3GPPMBMS server 10D and 3GPPMBMS client 20D compatible with 3GPP-MBMS are illustrated, and transports corresponding to these standards are illustrated. Although the case where the bearer is processed has been illustrated, when a standard other than ATSC3.0 and 3GPP-MBMS is supported, a server and a client corresponding to the standard may be provided. For example, when transmitting ROUTE data with a DVB (Digital Video Broadcasting) type IP broadcast (IP over MPEG2-TS) transport bearer, a DVB broadcast server corresponding to the DVB transport bearer is sent to the transmission side system 10, A DVB broadcast client corresponding to a DVB transport bearer may be added to the receiving system 20.

In addition, in the transmission system 1 of FIG. 10, only one receiving side system 20 is illustrated for convenience of explanation, but in reality, it is possible to receive content broadcasted simultaneously from the transmitting side system 10. A plurality (multiple) of receiving side systems 20 are provided. In the receiving system 20, for example, it is assumed that only the ATSC 3.0 is supported and the 3GPP-MBMS is not supported. In this case, the 3GPPMBMS client 20D is removed from the configuration, and the data The client 20A, the ROUTE client 20B, and the ATSC broadcast client 20C are configured.

Further, in FIG. 10, the transmission side system 10 has been described as being configured from a plurality of data servers 10 </ b> A to 3GPPMBMS server 10 </ b> D. You may make it catch as an apparatus (transmitter). Similarly, the receiving-side system 20 has been described as being composed of a plurality of clients of the data client 20A to 3GPPMBMS client 20D. However, the receiving-side system 20 has one receiving device (receiving device) having all the functions of those clients. May be considered as a machine).

<3. Extended LSID using this technology>

(1) Overview of LSID

(Configuration of ROUTE session)
FIG. 11 is a diagram showing a configuration of a ROUTE session.

As shown in FIG. 11, the ROUTE session can be configured by one or a plurality of LCT sessions. The ROUTE session is stored in the UDP header of the UDP packet and the source IP address (sIPAdrs: sourceIPIP address) and destination IP address (dIPAdrs: destination IP address), which are parameters stored in the IP header of the IP packet. It is identified by the port number (Port: port number). The LCT session is identified by a TSI (TransportTransSession Identifier) of an LCT packet (ALC / LCT packet).

A source IP address for identifying a ROUTE session by some signaling information (for example, SLS signaling information) transmitted from the transmission side system 10 (ROUTE server 10B) to the reception side system 20 (ROUTE client 20B), By notifying the destination IP address and the port number, it is possible to acquire the IP / UDP packet transmitted in the ROUTE session.

Furthermore, in the ROUTE session, LSID that is control information (control metafile) of ROUTE protocol can be acquired by filtering the LCT packet with TSI = 0. However, the LSID obtained by filtering the LCT packet in which TSI = 0 is obtained only when the LSID is transmitted in the ROUTE session.

(Configuration of LSID)
FIG. 12 is a diagram showing the configuration of the LSID.

As shown in FIG. 12, the LSID describes a source stream (SourceFlow) and a repair stream (RepairFlow) for each of one or a plurality of transport sessions (TransportSession). FIG. 13 shows a detailed description of the LSID. The LSID is an attribute for each LCT session (transport session) constituting the ROUTE session, in addition to the source stream and the repair stream, the LCT session. The TSI, etc., which is the identifier of the.

(Data acquisition flow using LSID)
FIG. 14 is a diagram for explaining the flow of data acquisition using the LSID in the receiving-side system 20.

In FIG. 14, the receiving-side system 20 acquires information on the ROUTE session from some signaling information notified from the transmitting-side system 10 (S11). In this signaling information, information related to the attributes of the ROUTE session 1 and the ROUTE session 2 in the broadcast stream transferred (transmitted) from the transmission side system 10 is described.

Here, as the attributes of ROUTE session 1, a source IP address “sIPAdrs1”, a destination IP address “dIPAdrs1”, and a port number “Port1” are designated. As attributes of the ROUTE session 2, a transmission source IP address “sIPAdrs1”, a transmission destination IP address “dIPAdrs2”, and a port number “Port1” are designated.

The receiving system 20 is identified by the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, and the port number “Port1” in accordance with the information about the attributes of the ROUTE session 1 in the signaling information. The IP / UDP packet transferred in the ROUTE session 1 is acquired (S12). In addition, the receiving-side system 20 can acquire LSID1, which is control information of the ROUTE session 1, by filtering the IP / UDP / LCT packet with TSI = "0" in the ROUTE session 1 (S13). ).

This LSID 1 includes information about the attributes of LCT session 1 and LCT session 2 as attributes of ROUTE session 1.

Here, TSI which is “tsi1” is specified as an attribute of LCT session 1. The receiving-side system 20 follows the information related to the attributes of the LCT session 1 in LSID1, the source IP address that is “sIPAdrs1”, the destination IP address that is “dIPAdrs1”, the port number that is “Port1”, and “tsi1”. The data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 1 identified by the TSI can be acquired (S14).

Also, TSI which is “tsi2” is specified as the attribute of LCT session 2. The receiving-side system 20 follows the information related to the attributes of the LCT session 2 in LSID1 and the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, the port number “Port1”, and “tsi2” Data (IP / UDP / LCT packet) transferred in the LCT session 2 of the ROUTE session 1 identified by the TSI can be acquired (S15).

On the other hand, in the signaling information, the attribute of ROUTE session 2 specifies the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, and the port number “Port1”. The receiving-side system 20 processes the ROUTE session 2 in the same manner as in the ROUTE session 1 described above.

That is, the receiving-side system 20 uses the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, and the port number “Port1” in accordance with the information related to the attributes of the ROUTE session 2 in the signaling information. An IP / UDP packet transferred in the identified ROUTE session 2 is acquired (S16). Further, the receiving-side system 20 can acquire LSID2 that is control information of the ROUTE session 2 by filtering the IP / UDP / LCT packet in which TSI = "0" in the ROUTE session 2 (S17). ).

This LSID 2 includes information about the attribute about the LCT session 1 as the attribute of the ROUTE session 2.

Here, TSI which is “tsi1” is specified as an attribute of LCT session 1. The receiving-side system 20 follows the information related to the attributes of the LCT session 1 in LSID2 and the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, the port number “Port1”, and “tsi1” Data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 2 identified by TSI can be acquired (S18).

As described above, the receiving system 20 acquires some signaling information, acquires the LSID transmitted in the ROUTE session, and uses the TSI described in the LSID to transmit in the LCT session of the ROUTE session. Data can be obtained.

(2) Extended LSID

By the way, in the processing using the LSID described above, in order to acquire data transmitted in the LCT session of the ROUTE session, it is necessary to acquire some signaling information, and the LSID transmitted in the ROUTE session is acquired. Since there was a necessity, there was a request to simplify the processing.

For this request, the LSID is expanded to include the source IP address, destination IP address, and port number. That is, by including the transmission source IP address, the transmission destination IP address, and the port number in the LSID, the process for acquiring data transmitted in the LCT session of the ROUTE session is simplified.

However, the source IP address is optional, and whether or not to include it in the extended LSID is arbitrary. In this specification, the LSID extended in this way is referred to as an extended LSID in order to distinguish it from the LSID already defined.

(Data acquisition flow using extended LSID)
FIG. 15 is a diagram for explaining the flow of data acquisition using the extended LSID in the reception-side system 20.

In FIG. 15, the receiving side system 20 acquires the extended LSID notified as SLS signaling information from the transmitting side system 10, for example (S21). In this extended LSID, information on attributes of the ROUTE session 1 and the ROUTE session 2 in the broadcast stream transferred (transmitted) from the transmission side system 10 is described.

Here, as the attributes of ROUTE session 1, a source IP address “sIPAdrs1”, a destination IP address “dIPAdrs1”, and a port number “Port1” are designated. Also, the attributes of the ROUTE session 1 include information regarding the attributes of the LCT session 1 and the LCT session 2.

That is, in the attribute of ROUTE session 1, TSI which is “tsi1” is specified for the attribute of LCT session 1, and TSI which is “tsi2” is specified for the attribute of LCT session 2.

Therefore, the receiving-side system 20 follows the information regarding the attributes of the ROUTE session 1 in the extended LSID (the attributes of the LCT session 1), the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, “Port1” The data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 1 identified by the TSI being “tsi1” and the port number being “tsi1” can be acquired (S22).

Similarly, the receiving-side system 20 follows the information regarding the attribute of the ROUTE session 1 (the attribute of the LCT session 2) in the extended LSID, the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, “ Data (IP / UDP / LCT packet) transferred in the LCT session 2 of the ROUTE session 1 identified by the port number “Port1” and the TSI “tsi2” can be acquired (S22).

On the other hand, in the extended LSID, the attribute of ROUTE session 2 specifies the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, and the port number “Port1”. In addition, the attribute of the ROUTE session 2 specifies TSI which is “tsi1” as the attribute of the LCT session 1, but the receiving side system 20 also has the case of the ROUTE session 2 in the case of the ROUTE session 1 described above. Process in the same way.

That is, the receiving-side system 20 follows the information about the attributes of the ROUTE session 2 in the extended LSID (the attributes of the LCT session 1), the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, “Port1” The data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 2 identified by the TSI being “tsi1” and the port number being “tsi1” can be acquired (S23).

Note that the extended LSID in FIG. 15 has been described on the assumption that one or a plurality of LCT session attributes are defined in the attributes of the ROUTE session. However, the structure of the extended LSID in FIG. May be adopted.

For example, as shown in FIG. 16, the source IP address, destination IP address, and port number are defined together with the TSI in the attributes of the LCT session without defining the attributes of the ROUTE session. Can do. Even when such an extended LSID is used, the receiving-side system 20 can specify one or more LCT sessions constituting the ROUTE session.

As described above, the extended LSID includes the transmission source IP address, the transmission destination IP address, and the port number, and the LCT session for each ROUTE session can be specified using only the extended LSID. Compared to the case where LSID is used, it is not necessary to acquire the LSID transmitted in the ROUTE session, so that the processing related to signaling information can be simplified. As a result, the process for obtaining data transmitted in the LCT session of the ROUTE session is simplified.

(3) Transport bearer identification by extended LSID

By the way, when a ROUTE session is transmitted on various transport bearers such as ATSC 3.0 and 3GPP-MBMS, information for mapping to each transport bearer is required. Therefore, a method for mapping the ROUTE session (one or a plurality of LCT sessions constituting the ROUTE session) to various transport bearers by extending the LSID will be described next.

The transport bearer corresponds to, for example, the physical layer (BroadcastroadPHY) in the ATSC3.0 protocol stack in FIG. 2 or the physical layer (MBMS or ptp Bearer (s)) in the 3GPP-MBMS protocol stack in FIG. 9. To do.

Here, examples of transport media include ATSC 3.0 transport, 3GPP-MBMS transport, and DVB IP broadcast transport. These transport media have different modulation parameters and encoding parameters, and become transport pipes having different transfer quality.

In the extended LSID, an identifier for identifying a transport bearer (hereinafter referred to as a transport bearer ID (BearerID)) is described as an attribute of each LCT session, so that a ROUTE session (an LCT session) and a transport bearer are described. To be mapped. Note that the format of the transport bearer ID is defined for each target transport medium.

(Data acquisition flow using extended LSID)
FIG. 17 is a diagram for explaining the flow of data acquisition using the extended LSID in which the transport bearer ID is described in the receiving system 20.

17, for example, the receiving system 20 acquires an extended LSID notified from the transmitting system 10 as SLS signaling information (S31). In this extended LSID, information on attributes of the LCT session 1 and the LCT session 2 of the ROUTE session 1 and the attributes of the LCT session 1 of the ROUTE session 2 in the broadcast stream transferred (transmitted) from the transmission side system 10 is described. Yes.

Here, as attributes of the LCT session 1 of the ROUTE session 1, the TSI being “tsi1”, the source IP address being “sIPAdrs1”, the destination IP address being “dIPAdrs1”, and the port number being “Port1” Is specified. Also, in the attribute of this LCT session 1, “atsc-bid1” and “3gpp-bid1” are designated as transport bearer IDs (BearerIDs) for identifying the transport bearers.

“Atsc-bidX” (X is an integer of 1 or more) is a transport bearer ID for identifying a transport bearer of ATSC 3.0. In the case of an ATSC 3.0 transport bearer, a combination of a broadcast stream ID (Broadcast Stream ID) and a PLPID (Physical Layer Pipe ID) is a transport bearer ID.

Here, the broadcast stream ID includes an area ID (Area ID) that is an identifier assigned to each broadcast wave arrival area and a frequency ID (Frequency ID) that is an identifier of a frequency band assigned to a broadcast wave of a certain channel. Assigned to a pair. PLPID is an identifier for each physical pipe when the frequency band identified by the broadcast stream ID is further divided into a plurality of physical pipes (PLP: Physical Layer Layer) having different modulation parameters and coding parameters.

"3gpp-bidX" (X is an integer of 1 or more) is a transport bearer ID for identifying a 3GPP-MBMS transport bearer. In the case of a 3GPP-MBMS transport bearer, TMGI (Temporary Mobile Group Identity) is the transport bearer ID.

Although not shown, in the case of a transport bearer for DVB IP broadcasts, an original network ID (ONID: Original Network ID), a transport ID (TID: Transporter ID), and a service ID (SID : DV (BV-Triplet) that is a combination with Service ID) is the transport bearer ID. The transport bearer ID may be further combined with an MPEG2 packet ID (PID: Packet ： ID).

Therefore, the receiving-side system 20 can connect to the ATSC3.0 transport bearer identified by the transport bearer ID “atsc-bid1” according to the information related to the attribute of the LCT session 1 in the extended LSID (S32). ). Similarly, the receiving-side system 20 can connect to the 3GPP-MBMS transport bearer identified by the transport bearer ID “3gpp-bid1” according to the information about the attributes of the LCT session 1 in the extended LSID ( S33).

Then, the receiving system 20 follows the information about the attributes of the LCT session 1 in the extended LSID, the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, the port number “Port1”, and Data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 1 identified by the TSI being “tsi1” can be acquired (S34). However, the LCT session 1 of the ROUTE session 1 is identified by the transport bearer ID of “atsc-bid1” or “3gpp-bid1” on the transport bearer of ATSC3.0 or 3GPP-MBMS. (S32, S33).

In FIG. 17, the extended LSID includes, as attributes of the LCT session 2 of the ROUTE session 1, a TSI that is “tsi2”, a source IP address that is “sIPAdrs1”, a destination IP address that is “dIPAdrs1”, and , "Port1" is specified as the port number. In the attribute of the LCT session 2, “atsc-bid2” is designated as a transport bearer ID for identifying the transport bearer.

The receiving-side system 20 can connect to the ATSC3.0 transport bearer identified by the transport bearer ID “atsc-bid2” according to the information related to the attribute of the LCT session 2 in the extended LSID (S35).

The receiving-side system 20 then follows the information about the attributes of the LCT session 2 in the extended LSID, the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs1”, the port number “Port1”, and Data (IP / UDP / LCT packet) transferred in the LCT session 2 of the ROUTE session 1 identified by the TSI being “tsi2” can be acquired (S36). However, the LCT session 2 of the ROUTE session 1 is transmitted on the ATSC3.0 transport bearer identified by the transport bearer ID “atsc-bid2” (S35).

Further, in FIG. 17, the extended LSID includes, as attributes of the LCT session 1 of the ROUTE session 2, a TSI that is “tsi1”, a source IP address that is “sIPAdrs1”, a destination IP address that is “dIPAdrs2”, and , "Port1" is specified as the port number. In addition, in the attribute of this LCT session 1, “atsc-bid3” and “3gpp-bid2” are designated as transport bearer IDs for identifying the transport bearer.

The receiving-side system 20 can connect to the ATSC3.0 transport bearer identified by the transport bearer ID “atsc-bid3” according to the information about the attributes of the LCT session 1 in the extended LSID (S37). Similarly, the receiving-side system 20 can connect to the 3GPP-MBMS transport bearer identified by the transport bearer ID “3gpp-bid2” according to the information about the attributes of the LCT session 1 in the extended LSID ( S38).

Then, the receiving system 20 follows the information about the attributes of the LCT session 1 in the extended LSID, the source IP address “sIPAdrs1”, the destination IP address “dIPAdrs2”, the port number “Port1”, and Data (IP / UDP / LCT packet) transferred in the LCT session 1 of the ROUTE session 2 identified by the TSI being “tsi1” can be acquired (S39). However, the LCT session 1 of the ROUTE session 2 is identified by the transport bearer ID of “atsc-bid3” or “3gpp-bid2” on the transport bearer of ATSC3.0 or 3GPP-MBMS. (S37, S38).

As described above, by describing the transport bearer ID in the attribute of each LCT session of the extended LSID, the ROUTE session (the LCT session) and the transport bearer are mapped. For example, ATSC3.0, 3GPP-MBMS, etc. A transport bearer transmitted by a plurality of transmission methods can be appropriately selected.

(Example of extended LSID structure)
Next, the extended LSID structure and its description example will be described with reference to FIGS.

(First structure)
FIG. 18 is a diagram illustrating a first structure of the extended LSID in the XML format.

In FIG. 18, for simplification of description, description of elements and attributes that overlap with the LSID of FIG. 13 in the extended LSID and are not directly related to the present technology is omitted. ing. In FIG. 18, “@” is added to the attribute among the elements and attributes. Further, the indented element and attribute are described for the upper element. These relationships are the same in other LSID structures described later.

In FIG. 18, the LSID element as the root element is an upper element of the TransportSession element. In the TransportSession element, information related to the transport session is specified.

The TransportSession element is an upper element of the tsi attribute, BroadcastStreamID attribute, PLPID attribute, TMGI attribute, DVBTriplet-pid attribute, sourceIPAddress attribute, destinationIPAddress attribute, port attribute, and SourceFlow element.

In the tsi attribute, TSI for identifying the LCT session is specified as the attribute value.

In BroadcastStreamID attribute, the broadcast stream ID specified by ATSC3.0 is specified as the attribute value. In the PLPID attribute, PLPID defined in ATSC 3.0 is specified as the attribute value. However, the BroadcastStreamID attribute and the PLPID attribute are optional attributes described when an ATSC 3.0 transport bearer is transmitted.

TMGI attribute specifies TMGI defined in 3GPP-MBMS as its attribute value. However, the TMGI attribute is an optional attribute described when a 3GPP-MBMS transport bearer is transmitted.

In DVBTriplet-pid attribute, a combination of DVB triplet which is a combination of original network ID, transport ID and service ID specified by DVB and packet ID is specified. However, the DVBTriplet-pid attribute is an optional attribute that is described when a transport bearer of a DVB IP broadcast is transmitted.

In the sourceIPAddress attribute, the source IP address is specified as the attribute value. In the destinationIPAddress attribute, the destination IP address is specified as the attribute value. In the port attribute, a port number is specified as the attribute value. However, the sourceIPAddress attribute, the destinationIPAddress attribute, and the port attribute are optional attributes.

In the SourceFlow element, information related to the source flow is specified as the attribute value. However, the SourceFlow element is an optional attribute.

Here, a specific description example of the first structure of the extended LSID defined in FIG. 18 will be described with reference to FIG. FIG. 19 shows an extended LSID when a transport bearer for ATSC 3.0, 3GPP-MBMS, and DVB IP broadcast is transmitted.

In FIG. 19, the TransportSession element carries ATSC3.0, 3GPP-MBMS, and DVB-based IP broadcast bearers. Therefore, in addition to the tsi attribute, among the optional attributes, the BroadcastStreamID attribute, the PLPID Attributes, TMGI attributes, and DVBTriplet-pid attributes are described.

In the tsi attribute, “xxx” is specified as the TSI value.

In the BroadcastStreamID attribute, “yyy” is specified as the broadcast stream ID. In the PLPID attribute, “zzz” is specified as the PLPID. That is, a transport bearer ID for identifying an ATSC 3.0 transport bearer is set by a combination of a broadcast stream ID “yyy” and a PLPID “zzz”.

In the TMGI attribute, “www” is specified as TMGI. That is, the transport bearer ID for identifying the 3GPP-MBMS transport bearer is set by TMGI which is “www”.

In the DVBTriplet-pid attribute, “onidX” is specified as the original network ID, “tsidX” as the transport ID, “sidX” as the service ID, and “pidX” as the packet ID. In other words, DVB IP broadcast transport by combining the original network ID "onidX", the transport ID "tsidX", the service ID "sidX", and the packet ID "pidX" A transport bearer ID for identifying the bearer is set.

So far, the first structure of the extended LSID in XML format has been described.

(Second structure)
FIG. 20 is a diagram illustrating a second structure of the extended LSID in the XML format.

The second structure of the extended LSID shown in FIG. 20 is different from the first structure of the extended LSID described above in that the identifier for each transport medium is structured, so that the element type for each transport medium is changed. It is defined as an independent XXXBearerID element.

In FIG. 20, the LSID element as the root element is an upper element of the TransportSession element. Here, the TransportSession element is an upper element of the ATSCBearerID element, the 3GPPBearerID element, and the DVBTSBearerID element in addition to the tsi attribute, the sourceIPAddress attribute, the destinationIPAddress attribute, the port attribute, and the SourceFlow element.

The ATSCBearerID element is an upper element of the BroadcastStreamID attribute for specifying the broadcast stream ID and the PLPID attribute for specifying the PLPID. That is, the ATSBearerID element stores a set of broadcast stream ID and PLPID. The ATSCBearerID element is an optional attribute described when an ATSC 3.0 transport bearer is transmitted.

The 3GPPBearerID element is a higher element of the TMGI attribute that specifies TMGI. That is, the 3GPPBearerID element stores TMGI. However, the 3GPPBearerID element is an optional attribute described when a 3GPP-MBMS transport bearer is transmitted.

The DVBTSBearerID element is an upper element of the DVBTriplet-pid attribute that specifies the DVB triplet and the pid attribute that specifies the packet ID. That is, the DVBTSBearerID element stores a set of DVB triplets and packet IDs. However, the DVBTSBearerID element is an optional attribute described when a transport bearer of DVB IP broadcast is transmitted.

Here, a specific description example of the second structure of the extended LSID defined in FIG. 20 will be described with reference to FIG. FIG. 21 shows an extended LSID when a transport bearer for ATSC 3.0, 3GPP-MBMS, and DVB IP broadcast is transmitted.

In FIG. 21, the TransportSession element carries ATSC3.0, 3GPP-MBMS, and DVB IP broadcast transport bearers, so among the optional attributes, the ATSCBearerID element, 3GPPBearerID element, and DVBTSBearerID The element is described.

In the ATSCBearerID element, “yyy” is specified as the broadcast stream ID in the BroadcastStreamID attribute, and “zzz” is specified as the PLPID in the PLPID attribute. That is, a transport bearer ID for identifying an ATSC 3.0 transport bearer is set by a combination of a broadcast stream ID “yyy” and a PLPID “zzz”.

In the 3GPPBearerID element, “www” is specified as TMGI in the TMGI attribute. That is, the transport bearer ID for identifying the 3GPP-MBMS transport bearer is set by TMGI which is “www”.

In DVBTSBearerID element, DVBTriplet-pid attribute specifies "onidX" as original network ID, "tsidX" as transport ID, "sidX" as service ID, and "pidX" as packet ID in pid attribute Has been. In other words, DVB IP broadcast transport by combining the original network ID "onidX", the transport ID "tsidX", the service ID "sidX", and the packet ID "pidX" A transport bearer ID for identifying the bearer is set.

So far, the second structure of the extended LSID in XML format has been described.

Note that the structure of the extended LSID shown in FIGS. 18 and 20 is an example, and other structures may be adopted. Further, although the case where the XML format is adopted as the description format of the extended LSID has been described, for example, a text format using a markup language other than the XML format, or a binary format may be used.

<4. Specific system operation example>

FIG. 22 is a diagram illustrating a specific operation example of the reception-side system 20 that processes a broadcast stream transmitted from the transmission-side system 10. Note that the operation example of FIG. 22 illustrates a case where a plurality of LCT sessions constituting a plurality of ROUTE sessions are transmitted by the ATSC3.0 transport bearer.

In FIG. 22, two broadcast waves identified by the broadcast stream ID are transmitted as broadcast streams that are on-air (On （Air Stream). The broadcast stream ID is assigned to a set of area ID and frequency ID.

On the broadcast stream identified by the broadcast stream ID “BSID1”, the FIT as the LLS signaling information and the PLPID physical pipe “PLPID1” are transmitted. On this physical pipe, a packet with an IP header storing an IP address “IPAdrs1” and a UDP header storing a port number “Port1” is transmitted.

In the payload of this packet, an LCT packet including an LCT header storing TSI “tsi-0” and an LCT payload storing SLS signaling information is arranged. In addition, as an LCT packet, an LCT header including an LCT header storing a TSI “tsi-v1”, an LCT payload storing a video 1 data, and an LCT header storing a TSI “tsi-a1” Then, an LCT packet including an LCT payload storing audio 1 data is arranged.

On the other hand, on the broadcast stream identified by the broadcast stream ID “BSID2”, the FIT as the LLS signaling information and the PLPID physical pipe “PLPID1” are transmitted. On this physical pipe, a packet to which an IP header storing an IP address “IPAdrs2” and a UDP header storing a port number “Port1” is added is transmitted. The payload of this packet includes an LCT header that stores an LCT header that stores TSI that is “tsi-v2”, an LCT payload that stores video 2 data, and an LCT header that stores a TSI that is “tsi-a2” Then, an LCT packet composed of an LCT payload storing audio 2 data is arranged.

In the receiving system 20 that receives such a broadcast stream, the following processing is performed.

The receiving side system 20 acquires the FIT transmitted by the broadcast stream identified by the broadcast stream ID which is “BSID1” (S51). The FIT describes bootstrap information for acquiring SLS signaling information for each service. This bootstrap information is a set of an IP address, a port number, a TSI, and a PLPID for acquiring SLS signaling information transmitted in a ROUTE session.

The receiving system 20 acquires SLS signaling information transmitted in the LCT session of the ROUTE session based on this bootstrap information (S52, S53). The SLS signaling information acquired in this way includes metadata such as USD (User Service Description), MPD (Media Presentation Description), LSID (Extended LSID). Reference destinations such as MPD and LSID are described in USD, and other metadata can be acquired by acquiring USD first.

The receiving system 20 acquires the MPD based on “mpdUri” specified in the mpdUri attribute of the userServiceDescription element of USD (S54). Further, the receiving system 20 acquires an LSID (extended LSID) based on “IsidUri” specified in the IsidUri attribute of the userServiceDescription element of USD (S55).

Here, in the MPD, a Period element, an AdaptationSet element, and a Representation element are described in a hierarchical structure. The Period element is a unit for describing the configuration of a service such as content. Further, the AdaptationSet element and the Representation element are used for each stream of video, audio, subtitles, etc., and can describe the attributes of each stream.

In the Representation element, the representation ID can be specified by the id attribute. In MPD, an attribute relating to the stream of video 1 is described in the Representation element identified by the representation ID “RepresentationID-v1”, and the Representation element identified by the representation ID “RepresentationID-v2” , Attributes relating to the stream of video 2 are described.

Also, in the MPD, the Representation element identified by the representation ID “RepresentationID-a1” describes attributes related to the stream of audio 1, and the Representation element identified by the representation ID “RepresentationID-a2”. Describes the attributes related to the stream of audio 2. In addition, by matching the URL specified in the Representation element of MPD with the URL specified in the DeliveryMethod element of USD, the distribution route of the video or audio stream will be either the broadcast route or the communication route Can be specified.

In the LSID (extended LSID), a tsi attribute, a BroadcastStreamID attribute, a PLPID attribute, a sourceIPAddress attribute, a destinationIPAddress attribute, and a port attribute are described for each TransportSession element. In the SourceFlow element, a representation ID is specified as an Applicationidentifier element. That is, this representation ID indicates the correspondence between the MPD Representation element and the LSID (extended LSID) transport session.

Of the TransportSession elements listed in LSID (extended LSID), the first TransportSession element specifies the broadcast stream ID “BSID1” and the PLPID “PLPID1”. Can be connected to the ATSC3.0 transport bearer identified by this transport bearer ID (S56). The first TransportSession element includes a source IP address “sIPArs1”, a destination IP address “IPArs1”, a port number “Port1”, and a TSI “tsi-v1”. It is specified. Therefore, the receiving side system 20 can acquire the data of video 1 (chunk file of the DASH segment file of video 1) transmitted in the LCT session of the ROUTE session by performing filtering using these parameters. (S56).

In the second TransportSession element, the broadcast stream ID “BSID1” and the PLPID “PLPID1” are specified, so that the receiving system 20 is identified by this transport bearer ID. Can be connected to the transport bearer (S57). The second TransportSession element includes a source IP address “sIPArs1”, a destination IP address “IPArs1”, a port number “Port1”, and a TSI “tsi-a1”. It is specified. Therefore, the receiving-side system 20 can acquire the audio 1 data (chunk file of the DASH segment file of audio 1) transmitted in the LCT session of the ROUTE session by performing filtering using these parameters. (S57).

In the third TransportSession element, the broadcast stream ID “BSID2” and the PLPID “PLPID1” are specified, so that the receiving system 20 is identified by this transport bearer ID. Can be connected to the other transport bearer (S58). The third TransportSession element includes a source IP address “sIPArs1”, a destination IP address “IPArs2”, a port number “Port1”, and a TSI “tsi-v2”. It is specified. Therefore, the receiving-side system 20 can acquire the video 2 data (chunk file of the DASH segment file of video 2) transmitted in the LCT session of the ROUTE session by performing filtering using these parameters. (S58).

In the fourth TransportSession element, the broadcast stream ID “BSID2” and the PLPID “PLPID1” are specified, so the receiving system 20 is identified by this transport bearer ID. Can be connected to the other transport bearer (S59). The fourth TransportSession element includes a source IP address “sIPArs1”, a destination IP address “IPArs2”, a port number “Port1”, and a TSI “tsi-a2”. It is specified. Therefore, the receiving-side system 20 can acquire the audio 2 data (chunk file of the DASH segment file of audio 2) transmitted in the LCT session of the ROUTE session by performing filtering using these parameters. (S59).

In the LSID (extended LSID) in FIG. 22, “2” is specified as the deliveryObjectFormatID element of the PayloadFormat element in the SourceFlow element. This is because the LCT payload format is a DASH segment file with an HTTP entity header. (Chunk).

<5. Configuration of each device in the system>

(Configuration example of sender system)
FIG. 23 is a diagram illustrating a configuration example of the transmission-side system 10 in FIG.

The transmission side system 10 includes a data server 10A, a ROUTE server 10B, an ATSC broadcast server 10C, and a 3GPPMBMS server 10D.

23, the data server 10A includes a control unit 111A, a session request unit 112A, a transmission / reception unit 113A, a data transfer processing unit 114A, and a data holding unit 115A.

The control unit 111A controls the operation of each unit of the data server 10A.

The session request unit 112A follows the control from the control unit 111A when transmitting data of content held in the data holding unit 115A (for example, content suitable for simultaneous broadcast delivery) in the ROUTE session (LCT session). Then, a request for establishing a ROUTE session to the ROUTE server 10B is supplied to the transmission / reception unit 113A.

The transmission / reception unit 113A exchanges various data with other servers such as the ROUTE server 10B in accordance with the control from the control unit 111A. The transmission / reception unit 113A transmits a request for establishing a ROUTE session to the ROUTE server 10B in accordance with the control from the control unit 111A.

The data transfer processing unit 114A acquires content data held in the data holding unit 115A and supplies it to the transmission / reception unit 113A in accordance with the control from the control unit 111A. The transmission / reception unit 113A transmits content data to the ROUTE server 10B in accordance with the control from the control unit 111A.

The data server 10A is configured as described above.

23, the ROUTE server 10B includes a control unit 111B, a session processing unit 112B, a transmission / reception unit 113B, an LSID generation unit 114B, and a ROUTE data generation unit 115B.

The control unit 111B controls the operation of each unit of the ROUTE server 10B.

The session processing unit 112B performs processing for transmitting content data in the ROUTE session according to control from the control unit 111B.

For example, the session processing unit 112B reserves ATSC3.0 transport resources for the ATSC broadcast server 10C when transmitting ROUTE data, which is content data transmitted in the ROUTE session, on the ATSC3.0 transport bearer. The request is supplied to the transmission / reception unit 113B. Further, for example, when the ROUTE data is transmitted on the 3GPP-MBMS transport bearer, the session processing unit 112B supplies a 3GPP-MBMS transport resource reservation request to the 3GPPMBMS server 10D to the transmission / reception unit 113B.

The transmission / reception unit 113B exchanges various data with other servers such as the ATSC broadcast server 10C and the 3GPPMBMS server 10D in accordance with the control from the control unit 111B. The transmission / reception unit 113B transmits an ATSC3.0 or 3GPP-MBMS transport resource reservation request to the ATSC broadcast server 10C or 3GPPMBMS server 10D in accordance with the control from the control unit 111B. Further, the transmission / reception unit 113B receives the ATSC3.0 or 3GPP-MBMS transport bearer ID transmitted from the ATSC broadcast server 10C or the 3GPPMBMS server 10D according to the control from the control unit 111B, and supplies it to the session processing unit 112B. To do.

The session processing unit 112B supplies the transport bearer ID of ATSC3.0 or 3GPP-MBMS supplied from the transmission / reception unit 113B to the LSID generation unit 114B in accordance with the control from the control unit 111B.

The LSID generation unit 114B generates an extended LSID based on the transport bearer ID of ATSC3.0 or 3GPP-MBMS supplied from the session processing unit 112B and the raw data of the extended LSID in accordance with the control from the control unit 111B. . Here, for example, the extended LSID of FIG. 19 and FIG. 21 is generated and supplied to the transmission / reception unit 113B. The transmission / reception unit 113B transmits the extended LSID supplied from the LSID generation unit 114B to the ATSC broadcast server 10C or the 3GPPMBMS server 10D according to the control from the control unit 111B.

The transmission / reception unit 113B receives the content data transmitted from the data server 10A and supplies the content data to the ROUTE data generation unit 115B in accordance with the control from the control unit 111B. The ROUTE data generation unit 115B generates ROUTE data based on the content data supplied from the transmission / reception unit 113B according to the control from the control unit 111B, and supplies the ROUTE data to the transmission / reception unit 113B. The transmission / reception unit 113B transmits the ROUTE data supplied from the ROUTE data generation unit 115B to the ATSC broadcast server 10C or the 3GPPMBMS server 10D according to the control from the control unit 111B.

The ROUTE server 10B is configured as described above.

23, the ATSC broadcast server 10C includes a control unit 111C, a bearer processing unit 112C, a transmission / reception unit 113C, a transfer processing unit 114C, and a transmission unit 115C.

The control unit 111C controls the operation of each unit of the ATSC broadcast server 10C. The transmission / reception unit 113C exchanges various data with other servers such as the ROUTE server 10B according to the control from the control unit 111C.

The transmission / reception unit 113C receives the ATSC3.0 transport resource reservation request transmitted from the ROUTE server 10B and supplies it to the bearer processing unit 112C. The bearer processing unit 112C secures the transport resource of ATSC 3.0 according to the reservation request supplied from the transmission / reception unit 113C according to the control from the control unit 111C.

The bearer processing unit 112C generates an ATSC3.0 transport bearer ID according to the reservation request supplied from the transmission / reception unit 113C, and supplies the generated transmission bearer ID to the transmission / reception unit 113C in accordance with the control from the control unit 111C. The transmission / reception unit 113C transmits the ATSC3.0 transport bearer ID supplied from the bearer processing unit 112C to the ROUTE server 10B in accordance with the control from the control unit 111C.

Further, the transmission / reception unit 113C receives the extended LSID transmitted from the ROUTE server 10B and supplies it to the transfer processing unit 114C. The transfer processing unit 114C performs processing for transferring the extended LSID according to control from the control unit 111C, and supplies the extended LSID to the transmission unit 115C. The transmission unit 115C transmits (transfers) the extended LSID supplied from the transfer processing unit 114C to the reception-side system 20 (ATSC broadcast client 20C) via the transmission path 80 via the antenna 116C.

Furthermore, the transmission / reception unit 113C receives the ROUTE data transmitted from the ROUTE server 10B and supplies it to the transfer processing unit 114C. In accordance with control from the control unit 111C, the transfer processing unit 114C performs processing for transmitting the ROUTE data on the ATSC3.0 transport bearer, and supplies the bearer data obtained thereby to the transmission unit 115C. . The transmission unit 115C transmits (transfers) the bearer data supplied from the transfer processing unit 114C to the reception-side system 20 (ATSC broadcast client 20C) via the transmission path 80 via the antenna 116C.

The ATSC broadcast server 10C is configured as described above.

23, the 3GPPMBMS server 10D includes a control unit 111D, a bearer processing unit 112D, a transmission / reception unit 113D, a transfer processing unit 114D, and a transmission unit 115D.

The control unit 111D controls the operation of each unit of the 3GPPMBMS server 10D. Further, the transmission / reception unit 113D exchanges various data with other servers such as the ROUTE server 10B in accordance with the control from the control unit 111D.

The transmission / reception unit 113D receives the 3GPP-MBMS transport resource reservation request transmitted from the ROUTE server 10B and supplies it to the bearer processing unit 112D. The bearer processing unit 112D secures 3GPP-MBMS transport resources according to the reservation request supplied from the transmission / reception unit 113D in accordance with the control from the control unit 111D.

The bearer processing unit 112D generates a 3GPP-MBMS transport bearer ID in response to a reservation request supplied from the transmission / reception unit 113D, and supplies it to the transmission / reception unit 113D in accordance with the control from the control unit 111D. The transmission / reception unit 113D transmits the 3GPP-MBMS transport bearer ID supplied from the bearer processing unit 112D to the ROUTE server 10B in accordance with the control from the control unit 111D.

Further, the transmission / reception unit 113D receives the extended LSID transmitted from the ROUTE server 10B and supplies it to the transfer processing unit 114D. The transfer processing unit 114D performs processing for transferring the extended LSID in accordance with control from the control unit 111D, and supplies it to the transmission unit 115D. The transmission unit 115D transmits (transfers) the extended LSID supplied from the transfer processing unit 114D to the reception-side system 20 (3GPPMBMS client 20D) via the transmission path 80 via the antenna 116D.

Furthermore, the transmission / reception unit 113D receives the ROUTE data transmitted from the ROUTE server 10B and supplies it to the transfer processing unit 114D. The transfer processing unit 114D performs processing for transmitting the ROUTE data on the 3GPP-MBMS transport bearer according to the control from the control unit 111D, and supplies the bearer data obtained thereby to the transmission unit 115D. . The transmission unit 115D transmits (transfers) the bearer data supplied from the transfer processing unit 114D to the reception-side system 20 (3GPPMBMS client 20D) via the transmission path 80 via the antenna 116D.

3GPPMBMS server 10D is configured as described above.

(Example configuration of receiving system)
FIG. 24 is a diagram illustrating a configuration example of the reception-side system 20 in FIG.

The receiving side system 20 includes a data client 20A, a ROUTE client 20B, an ATSC broadcast client 20C, and a 3GPPMBMS client 20D.

24, the 3GPPMBMS client 20D includes a control unit 211D, a reception unit 212D, a transfer processing unit 213D, and a transmission / reception unit 214D.

The control unit 211D controls the operation of each unit of the 3GPPMBMS client 20D.

The receiving unit 212D receives the extended LSID transmitted from the transmission side system 10 (3GPPMBMS server 10D) via the transmission path 90 according to the control from the control unit 211D via the antenna 215D, and sends it to the transfer processing unit 213D. Supply. The transfer processing unit 213D performs processing for transferring the extended LSID in accordance with control from the control unit 211D, and supplies it to the transmission / reception unit 214D. The transmission / reception unit 214D transmits the extended LSID supplied from the transfer processing unit 213D to the ROUTE client 20B in accordance with the control from the control unit 211D.

The receiving unit 212D receives bearer data transmitted from the transmission side system 10 (3GPPMBMS server 10D) via the transmission path 90 through the antenna 215D according to the control from the control unit 211D, and sends it to the transfer processing unit 213D. Supply. The transfer processing unit 213D processes bearer data for transmitting ROUTE data on the 3GPP-MBMS transport bearer according to the control from the control unit 211D, and supplies the processed data to the transmission / reception unit 214D. The transmission / reception unit 214D transmits bearer data supplied from the transfer processing unit 213D to the ROUTE client 20B in accordance with the control from the control unit 211D.

3GPPMBMS client 20D is configured as described above.

24, the ATSC broadcast client 20C includes a control unit 211C, a reception unit 212C, a transfer processing unit 213C, and a transmission / reception unit 214C.

The control unit 211C controls the operation of each unit of the ATSC broadcast client 20C.

In accordance with control from the control unit 211C, the reception unit 212C receives the extended LSID transmitted from the transmission-side system 10 (ATSC broadcast server 10C) via the transmission path 80 via the antenna 215C, and transfers the transfer processing unit 213C. To supply. The transfer processing unit 213C performs processing for transferring the extended LSID in accordance with the control from the control unit 211C, and supplies the processing to the transmission / reception unit 214C. The transmission / reception unit 214C transmits the extended LSID supplied from the transfer processing unit 213C to the ROUTE client 20B in accordance with the control from the control unit 211C.

The receiving unit 212C receives bearer data transmitted from the transmission-side system 10 (ATSC broadcast server 10C) via the transmission path 80 via the antenna 215C according to the control from the control unit 211C, and transfers the transfer processing unit 213C. To supply. The transfer processing unit 213C processes bearer data for transmitting the ROUTE data on the ATSC3.0 transport bearer according to the control from the control unit 211C, and supplies the processed data to the transmission / reception unit 214C. The transmission / reception unit 214C transmits bearer data supplied from the transfer processing unit 213C to the ROUTE client 20B in accordance with control from the control unit 211C.

The ATSC broadcast client 20C is configured as described above.

24, the ROUTE client 20B includes a control unit 211B, a transmission / reception unit 212B, an LSID analysis unit 213B, and a transfer processing unit 214B.

The control unit 211B controls the operation of each unit of the ROUTE client 20B.

The transmission / reception unit 212B receives the extended LSID transmitted from the 3GPPMBMS client 20D or the ATSC broadcast client 20C according to the control from the control unit 211B, and supplies it to the LSID analysis unit 213B.

The LSID analysis unit 213B analyzes the extended LSID supplied from the transmission / reception unit 212B (for example, the extended LSID in FIGS. 19 and 21) according to the control from the control unit 211B, and supplies the analysis result to the transfer processing unit 214B. To do. In addition, the LSID analysis unit 213B selects a transport bearer for acquiring ROUTE data in accordance with the analysis result of the extended LSID, and supplies the selection result to the transfer processing unit 214B.

The transmission / reception unit 212B receives bearer data transmitted from the 3GPPMBMS client 20D or the ATSC broadcast client 20C according to the control from the control unit 211B, and supplies it to the transfer processing unit 214B. The transfer processing unit 214B selects bearer data (3GPP-MBMS or ATSC3.0 transport bearer) according to the transport bearer selection result from the LSID analysis unit 213B. Further, the transfer processing unit 214B acquires ROUTE data transmitted by the selected bearer data (on 3GPP-MBMS or ATSC3.0 transport bearer), and supplies the ROUTE data to the transmission / reception unit 212B.

The transmission / reception unit 212B transmits the ROUTE data supplied from the transfer processing unit 214B to the data client 20A in accordance with the control from the control unit 211B.

The ROUTE client 20B is configured as described above.

24, the data client 20A includes a control unit 211A, a transmission / reception unit 212A, a reproduction control unit 213A, a display unit 214A, and a speaker 215A.

The control unit 211A controls the operation of each unit of the data client 20A.

The transmission / reception unit 212A receives the ROUTE data transmitted from the ROUTE client 20B according to the control from the control unit 211A and supplies it to the reproduction control unit 213A.

The reproduction control unit 213A performs a rendering process on the ROUTE data supplied from the transmission / reception unit 212A according to the control from the control unit 211A. Through this rendering process, video data of content (for example, content suitable for simultaneous broadcast delivery) is supplied to the display unit 214A, and audio data is supplied to the speaker 215A.

Display unit 214A displays video corresponding to the video data supplied from playback control unit 213A in accordance with control from control unit 211A. Further, the speaker 215A outputs sound corresponding to the audio data supplied from the reproduction control unit 213A according to the control from the control unit 211A.

The data client 20A is configured as described above.

<6. Flow of processing executed by each device of the system>

Next, the flow of processing executed by each device constituting the transmission system 1 and the reception system 20 constituting the transmission system 1 will be described.

(Processing flow of each device in the sending system)
First, with reference to the flowchart of FIG. 25, the flow of processing of each device constituting the transmission side system 10 will be described.

In step S111, the session request unit 112A of the data server 10A requests the ROUTE server 10B to establish a ROUTE session by controlling the transmission / reception unit 113A according to the control from the control unit 111A. The session establishment request from the data server 10A is received by the transmission / reception unit 113B of the ROUTE server 10B.

In step S131, the session processing unit 112B of the ROUTE server 10B determines whether a session establishment request from the data server 10A requests distribution using an ATSC 3.0 transport bearer.

If it is determined in step S131 that distribution using an ATSC 3.0 transport bearer is requested, the process proceeds to step S132. In step S132, the session processing unit 112B of the ROUTE server 10B requests the ATSC broadcast server 10C to reserve the transport resource of ATSC3.0 by controlling the transmission / reception unit 113B according to the control from the control unit 111B. To do. The ATSC 3.0 transport resource reservation request from the ROUTE server 10B is received by the transmission / reception unit 113C of the ATSC broadcast server 10C.

In step S151, the bearer processing unit 112C of the ATSC broadcast server 10C secures the transport resource of ATSC 3.0 according to the reservation request for the transport resource of ATSC 3.0 according to the control from the control unit 111C.

In step S152, the bearer processing unit 112C of the ATSC broadcast server 10C generates an ATSC3.0 transport bearer ID according to the control from the control unit 111C, and notifies the ROUTE server 10B via the transmission / reception unit 113C. The ATSC 3.0 transport bearer ID from the ATSC broadcast server 10C is received by the transmission / reception unit 113B of the ROUTE server 10B.

If it is determined in step S131 that delivery using an ATSC 3.0 transport bearer is not requested, the processes in steps S132, S151, and S152 described above are skipped.

In step S133, the session processing unit 112B of the ROUTE server 10B determines whether a session establishment request from the data server 10A requests distribution using a 3GPP-MBMS transport bearer.

If it is determined in step S133 that distribution using the 3GPP-MBMS transport bearer is requested, the process proceeds to step S134. In step S134, the session processing unit 112B of the ROUTE server 10B requests the 3GPP-MBMS transport resource reservation to the 3GPPMBMS server 10D by controlling the transmission / reception unit 113B according to the control from the control unit 111B. . The 3GPP-MBMS transport resource reservation request from the ROUTE server 10B is received by the transmission / reception unit 113D of the 3GPPMBMS server 10D.

In step S171, the bearer processing unit 112D of the 3GPPMBMS server 10D secures the 3GPP-MBMS transport resource according to the 3GPP-MBMS transport resource reservation request in accordance with the control from the control unit 111D.

In step S172, the bearer processing unit 112D of the 3GPPMBMS server 10D generates a 3GPP-MBMS transport bearer ID according to the control from the control unit 111D, and notifies the ROUTE server 10B via the transmission / reception unit 113D. The 3GPP-MBMS transport bearer ID from the 3GPPMBMS server 10D is received by the transmission / reception unit 113B of the ROUTE server 10B.

If it is determined in step S133 that distribution using the 3GPP-MBMS transport bearer is not requested, the processes in steps S134, S171, and S172 described above are skipped.

In step S135, the LSID generation unit 114B of the ROUTE server 10B generates an ATSC 3.0 or 3GPP-MBMS transport bearer ID and an extended LSID supplied from the session processing unit 112B in accordance with the control from the control unit 111B. Based on the raw data, an extended LSID (for example, the extended LSID in FIGS. 19 and 21) is generated.

In step S136, the transmission / reception unit 113B of the ROUTE server 10B transmits the extended LSID generated in the process of step S135 to at least one of the ATSC broadcast server 10C or the 3GPPMBMS server 10D according to the control of the control unit 111B.

In step S153, when the extended LSID from the ROUTE server 10B is received, the transfer processing unit 114C of the ATSC broadcast server 10C receives from the ROUTE server 10B by controlling the transmission unit 115C according to the control from the control unit 111C. The extended LSID is transmitted (transferred) to the receiving system 20 (ATSC broadcast client 20C) via the transmission path 80.

In step S173, when the extended LSID from the ROUTE server 10B is received, the transfer processing unit 114D of the 3GPPMBMS server 10D receives from the ROUTE server 10B by controlling the transmission unit 115D according to the control from the control unit 111D. The extended LSID is transmitted (transferred) to the receiving system 20 (3GPPMBMS client 20D) via the transmission path 90.

In step S112, the data transfer processing unit 114A of the data server 10A acquires the data of the content held in the data holding unit 115A according to the control from the control unit 111A, and controls the transmission / reception unit 113A to obtain the data. Transmit to the ROUTE server 10B. Data from the data server 10A is received by the transmission / reception unit 113B of the ROUTE server 10B.

In step S137, the ROUTE data generation unit 115B of the ROUTE server 10B generates ROUTE data for transmitting the data in the ROUTE session based on the data from the transmission / reception unit 113B according to the control from the control unit 111B.

In step S138, the transmission / reception unit 113B of the ROUTE server 10B transmits the ROUTE data generated in the process of step S137 to at least one of the ATSC broadcast server 10C or the 3GPPMBMS server 10D in accordance with the control from the control unit 111B.

Here, when it is determined in the process of step S131 that delivery using an ATSC 3.0 transport bearer is performed, and an extended LSID including an ATSC 3.0 transport bearer ID from the ATSC broadcast server 10C is generated. The ROUTE data generated in step S137 is transmitted to the ATSC broadcast server 10C. If it is determined in step S133 that distribution using the 3GPP-MBMS transport bearer is performed and an extended LSID including the 3GPP-MBMS transport bearer ID from the 3GPPMBMS server 10D is generated, The ROUTE data generated by the process of S137 is transmitted to the 3GPPMBMS server 10D.

In step S154, when the ROUTE data from the ROUTE server 10B is received, the transfer processing unit 114C of the ATSC broadcast server 10C receives the ROUTE data received from the ATSC broadcast server 10C according to the control from the control unit 111C. To be transmitted on the other transport bearer. Then, the transfer processing unit 114C controls the transmission unit 115C in accordance with the control from the control unit 111C, thereby transferring bearer data (ROUTE data transmitted on the transport bearer of ATSC 3.0) via the transmission path 80. To the receiving system 20 (ATSC broadcast client 20C).

In step S174, when the ROUTE data from the ROUTE server 10B is received, the transfer processing unit 114D of the 3GPPMBMS server 10D converts the ROUTE data received from the ATSC broadcast server 10C according to the control from the control unit 111D to the 3GPP-MBMS. Process to be transmitted on transport bearer. Then, the transfer processing unit 114D controls bearer data (ROUTE data transmitted on the 3GPP-MBMS transport bearer) via the transmission path 90 by controlling the transmission unit 115D according to the control from the control unit 111D. To the receiving system 20 (3GPPMBMS client 20D).

In the foregoing, the processing flow of each device constituting the transmission side system 10 has been described.

(Processing flow of each device in the receiving system)
Next, with reference to the flowchart of FIG. 26, the flow of processing of each device constituting the receiving system 20 will be described.

In step S211, it is determined whether 3GPP-MBMS is being distributed. If it is determined in step S211 that 3GPP-MBMS distribution is being performed, the process proceeds to step S212.

In step S212, the reception unit 212D of the 3GPPMBMS client 20D receives the extended LSID transmitted from the transmission side system 10 (3GPPMBMS server 10D) via the transmission path 90. In step S213, the transfer processing unit 213D transfers the extended LSID received in step S212 to the ROUTE client 20B by controlling the transmission / reception unit 214D according to the control from the control unit 211D.

If it is determined in step S211 that 3GPP-MBMS is not distributed, the processes in steps S212 and S213 described above are skipped.

In step S231, it is determined whether or not ATSC 3.0 is being distributed. If it is determined in step S231 that ATSC 3.0 is being distributed, the process proceeds to step S232.

In step S232, the reception unit 212C of the ATSC broadcast client 20C receives the extended LSID transmitted from the transmission side system 10 (ATSC broadcast server 10C) via the transmission path 80. In step S233, the transfer processing unit 213C transfers the extended LSID received in step S232 to the ROUTE client 20B by controlling the transmission / reception unit 214C in accordance with the control from the control unit 211C.

If it is determined in step S231 that ATSC 3.0 is not distributed, the processes in steps S232 and S233 described above are skipped.

The extended LSID transmitted from the 3GPPMBMS client 20D or the ATSC broadcast client 20C is received by the transmission / reception unit 212B of the ROUTE client 20B.

In step S251, the LSID analysis unit 213B analyzes the extended LSID (for example, the extended LSID in FIGS. 19 and 21) from the 3GPPMBMS client 20D or the ATSC broadcast client 20C. In step S252, the LSID analysis unit 213B selects a transport bearer for acquiring ROUTE data transmitted in the ROUTE session (the LCT session) according to the analysis result in step S252.

In step S214, it is determined whether 3GPP-MBMS is being distributed. If it is determined in step S214 that 3GPP-MBMS distribution is being performed, the process proceeds to step S215.

In step S215, the reception unit 212D of the 3GPPMBMS client 20D receives bearer data (ROUTE data transmitted on the 3GPP-MBMS transport bearer) transmitted from the 3GPPMBMS server 10D via the transmission path 90. In step S216, the transfer processing unit 213D transfers the bearer data received in the process of step S215 to the ROUTE client 20B by controlling the transmission / reception unit 214D according to the control from the control unit 211D.

If it is determined in step S214 that 3GPP-MBMS is not distributed, the processes in steps S215 and S216 described above are skipped.

In step S234, it is determined whether or not ATSC 3.0 is being distributed. If it is determined in step S234 that ATSC 3.0 is being distributed, the process proceeds to step S235.

In step S235, the receiving unit 212C of the ATSC broadcast client 20C receives bearer data (ROUTE data transmitted on the ATSC 3.0 transport bearer) transmitted from the ATSC broadcast server 10C via the transmission path 80. . In step S236, the transfer processing unit 213C transfers the bearer data received in the process of step S235 to the ROUTE client 20B by controlling the transmission / reception unit 214C according to the control from the control unit 211C.

If it is determined in step S234 that ATSC 3.0 is not distributed, the processes in steps S235 and S236 described above are skipped.

Bearer data from 3GPPMBMS client 20D (ROUTE data transmitted on 3GPP-MBMS transport bearer) or bearer data from ATSC broadcast client 20C (ROUTE data transmitted on ATSC3.0 transport bearer) Is received by the transmission / reception unit 212B of the ROUTE client 20B.

In step S253, the transfer processing unit 214B of the ROUTE client 20B acquires ROUTE data transmitted on the 3GPP-MBMS or ATSC 3.0 transport bearer according to the transport bearer selection result in step S252.

In step S254, the transfer processing unit 214B transfers the ROUTE data acquired in the process of step S253 to the data client 20A by controlling the transmission / reception unit 212B according to the control from the control unit 211B.

In step S271, the transmission / reception unit 212A of the data client 20A receives the ROUTE data transmitted from the ROUTE client 20B in accordance with the control from the control unit 211A.

In step S272, the reproduction processing unit 213A performs rendering processing on the ROUTE data received in step S271 according to the control from the control unit 211A. Through this rendering process, the video data of the content is supplied to the display unit 214A, and the audio data is supplied to the speaker 215A. Thereby, the video of the content is displayed on the display unit 214A, and the sound is output from the speaker 215A.

The processing flow of each device constituting the receiving system 20 has been described above.

<7. Modification>

In addition, as the above-mentioned explanation, as a standard of digital television broadcasting, ATSC which is a method mainly adopted in the United States and the like has been explained. However, ISDB (Integrated Services Digital Broadcasting) or a method adopted by Japan and the like It may be applied to DVB which is a method adopted by European countries. Further, the present invention is not limited to terrestrial digital television broadcasting, but may be adopted for satellite digital television broadcasting, digital cable television broadcasting, and the like.

In the above description, the elements and attributes are described when the signaling information is described in a markup language such as XML. However, the names of the elements and attributes are examples, and other names are adopted. You may be made to do. For example, a broadcast stream ID defined in LSID or the like may be referred to as an RF channel ID (RF Channel ID), a network ID (Network ID), an RF allocation ID (RF Alloc ID), or the like. However, the difference between these names is a formal difference, and the substantial contents of those elements and attributes are not different. Similarly, the name of the signaling information is an example, and another name may be adopted.

<8. Computer configuration>

The series of processes described above can be executed by hardware or software. When a series of processing is executed by software, a program constituting the software is installed in the computer. FIG. 27 is a diagram illustrating a configuration example of hardware of a computer that executes the above-described series of processing by a program.

In the computer 900, a CPU (Central Processing Unit) 901, a ROM (Read Only Memory) 902, and a RAM (Random Access Memory) 903 are connected to each other by a bus 904. An input / output interface 905 is further connected to the bus 904. An input unit 906, an output unit 907, a recording unit 908, a communication unit 909, and a drive 910 are connected to the input / output interface 905.

The input unit 906 includes a keyboard, a mouse, a microphone, and the like. The output unit 907 includes a display, a speaker, and the like. The recording unit 908 includes a hard disk, a nonvolatile memory, and the like. The communication unit 909 includes a network interface or the like. The drive 910 drives a removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.

In the computer 900 configured as described above, the CPU 901 loads the program recorded in the ROM 902 or the recording unit 908 to the RAM 903 via the input / output interface 905 and the bus 904, and executes the program. A series of processing is performed.

The program executed by the computer 900 (CPU 901) can be provided by being recorded on a removable medium 911 as a package medium, for example. The program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.

In the computer 900, the program can be installed in the recording unit 908 via the input / output interface 905 by installing the removable medium 911 in the drive 910. Further, the program can be received by the communication unit 909 via a wired or wireless transmission medium and installed in the recording unit 908. In addition, the program can be installed in the ROM 902 or the recording unit 908 in advance.

Here, in the present specification, the processing performed by the computer according to the program does not necessarily have to be performed in chronological order in the order described as the flowchart. That is, the processing performed by the computer according to the program includes processing executed in parallel or individually (for example, parallel processing or object processing). The program may be processed by a single computer (processor) or may be distributedly processed by a plurality of computers.

Note that the embodiments of the present technology are not limited to the above-described embodiments, and various modifications can be made without departing from the gist of the present technology.

Also, the present technology can take the following configurations.

(1)
Information for acquiring data transmitted in a session of the first transmission method in a first layer in a protocol stack of an IP (Internet Protocol) transmission method, and a second lower layer than the first layer An acquisition unit for acquiring control information including information for identifying a bearer that transmits the data by a second transmission method in a layer;
And a control unit that controls an operation of each unit that acquires the data transmitted on the bearer based on the control information.
(2)
The first layer is a transport layer;
The receiving device according to (1), wherein the second layer is a physical layer.
(3)
The receiving apparatus according to (1) or (2), wherein the control information includes a bearer ID for identifying the bearer.
(4)
The receiving apparatus according to any one of (1) to (3), wherein the control information includes an IP address and a port number for identifying the session.
(5)
The first transmission method is ROUTE (Real-time Object Delivery over Unidirectional Transport),
The session is one or more LCT (Layered Coding Transport) sessions constituting a ROUTE session,
The receiving apparatus according to any one of (1) to (4), wherein the control information is LSID (LCT Session Instance Description).
(6)
The second transmission system includes ATSC (Advanced Television Systems Committee) 3.0 and 3GPP-MBMS (Third Generation Partnership Project-Multimedia Broadcast Multicast Service),
The bearer ID of ATSC3.0 is
A first identifier that is a set of an identifier assigned to each broadcast wave arrival area and a frequency band identifier assigned to a broadcast wave of a predetermined channel;
A combination of a second identifier for identifying each physical pipe when the frequency band identified by the first identifier is divided into a plurality of physical pipes having different parameters.
The bearer ID of the 3GPP-MBMS is TMGI (Temporary Mobile Group Identity). The receiving device according to any one of (3) to (5).
(7)
In the receiving method of the receiving device,
The receiving device is
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. Obtaining control information including information for identifying a bearer transmitting the data according to the transmission method of
A receiving method comprising: controlling an operation of each unit that acquires the data transmitted on the bearer based on the control information.
(8)
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. A generating unit that generates control information including information for identifying a bearer that transmits the data according to the transmission method;
A transmission apparatus comprising: a transmission unit that transmits the data by the bearer identified by information included in the control information together with the control information.
(9)
The first layer is a transport layer;
The transmitting apparatus according to (8), wherein the second layer is a physical layer.
(10)
The transmission device according to (8) or (9), wherein the control information includes a bearer ID for identifying the bearer.
(11)
The transmission device according to any one of (8) to (10), wherein the control information includes an IP address and a port number for identifying the session.
(12)
The first transmission method is ROUTE,
The session is one or more LCT sessions constituting a ROUTE session,
The transmission apparatus according to any one of (8) to (11), wherein the control information is an LSID.
(13)
The second transmission method includes ATSC3.0 and 3GPP-MBMS,
The bearer ID of ATSC3.0 is
A first identifier that is a set of an identifier assigned to each broadcast wave arrival area and a frequency band identifier assigned to a broadcast wave of a predetermined channel;
A combination of a second identifier for identifying each physical pipe when the frequency band identified by the first identifier is divided into a plurality of physical pipes having different parameters.
The transmitting apparatus according to any one of (10) to (12), wherein the 3GPP-MBMS bearer ID is TMGI.
(14)
In the transmission method of the transmission device,
The transmitting device is
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. Generating control information including information for identifying a bearer transmitting the data according to the transmission method of
A transmission method including the step of transmitting the data by the bearer identified by the information included in the control information together with the control information.

1 transmission system, 10 sender system, 10A data server, 10B ROUTE server, 10C ATSC broadcast server, 10D 3GPPMBMS server, 20 receiver system, 20A data client, 20B ROUTE client, 20C ATSC broadcast client, 20D 3GPPMBMS client, 80 transmission Path, 90 transmission path, 114B LSID generation section, 115B ROUTE data generation section, 114C transfer processing section, 115C transmission section, 114D transfer processing section, 115D transmission section, 213A playback control section, 213B LSID analysis section, 214B transfer processing section, 212C receiving unit, 213C transfer processing unit, 212D receiving unit, 213D transfer processing unit, 900 computer, 901 CPU

Claims

Information for acquiring data transmitted in a session of the first transmission method in a first layer in a protocol stack of an IP (Internet Protocol) transmission method, and a second lower layer than the first layer An acquisition unit for acquiring control information including information for identifying a bearer that transmits the data by a second transmission method in a layer;
And a control unit that controls an operation of each unit that acquires the data transmitted on the bearer based on the control information.
The first layer is a transport layer;
The receiving apparatus according to claim 1, wherein the second layer is a physical layer.
The receiving apparatus according to claim 2, wherein the control information includes a bearer ID for identifying the bearer.
The receiving apparatus according to claim 3, wherein the control information includes an IP address and a port number for identifying the session.
The first transmission method is ROUTE (Real-time Object Delivery over Unidirectional Transport),
The session is one or more LCT (Layered Coding Transport) sessions constituting a ROUTE session,
The receiving apparatus according to claim 4, wherein the control information is LSID (LCT Session Instance Description).
The second transmission system includes ATSC (Advanced Television Systems Committee) 3.0 and 3GPP-MBMS (Third Generation Partnership Project-Multimedia Broadcast Multicast Service),
The bearer ID of ATSC3.0 is
A first identifier that is a set of an identifier assigned to each broadcast wave arrival area and a frequency band identifier assigned to a broadcast wave of a predetermined channel;
A combination of a second identifier for identifying each physical pipe when the frequency band identified by the first identifier is divided into a plurality of physical pipes having different parameters.
The receiving apparatus according to claim 5, wherein the 3GPP-MBMS bearer ID is TMGI (Temporary Mobile Group Identity).
In the receiving method of the receiving device,
The receiving device is
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. Obtaining control information including information for identifying a bearer transmitting the data according to the transmission method of
A receiving method comprising: controlling an operation of each unit that acquires the data transmitted on the bearer based on the control information.
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. A generating unit that generates control information including information for identifying a bearer that transmits the data according to the transmission method;
A transmission apparatus comprising: a transmission unit that transmits the data by the bearer identified by information included in the control information together with the control information.
The first layer is a transport layer;
The transmission apparatus according to claim 8, wherein the second layer is a physical layer.
The transmission apparatus according to claim 9, wherein the control information includes a bearer ID for identifying the bearer.
The transmission device according to claim 10, wherein the control information includes an IP address and a port number for identifying the session.
The first transmission method is ROUTE,
The session is one or more LCT sessions constituting a ROUTE session,
The transmission apparatus according to claim 11, wherein the control information is an LSID.
The second transmission method includes ATSC3.0 and 3GPP-MBMS,
The bearer ID of ATSC3.0 is
A first identifier that is a set of an identifier assigned to each broadcast wave arrival area and a frequency band identifier assigned to a broadcast wave of a predetermined channel;
A combination of a second identifier for identifying each physical pipe when the frequency band identified by the first identifier is divided into a plurality of physical pipes having different parameters.
The transmission device according to claim 12, wherein the 3GPP-MBMS bearer ID is TMGI.
In the transmission method of the transmission device,
The transmitting device is
Information for acquiring data to be transmitted in a session using the first transmission method in the first layer in the protocol stack of the IP transmission method, and the second layer in the second layer lower than the first layer. Generating control information including information for identifying a bearer transmitting the data according to the transmission method of
A transmission method including the step of transmitting the data by the bearer identified by the information included in the control information together with the control information.