Broadcast Receiver NRT Service Processing via FLUTE Signaling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing broadcast receivers lack the capability to properly receive and process non-real-time (NRT) services due to the absence of a means for processing NRT service signaling information, leading to difficulties in identifying and processing NRT content alongside real-time services.
Innovation Solution
A method is introduced to define and provide signaling information for NRT services, allowing receivers to identify and process NRT content by allocating unique packet identifiers and using protocols like FLUTE and ALC/LCT for packetization, and DSM-CC for transport, enabling proper reception and processing of NRT services.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If broadcast receivers use conventional receiving methods for real-time services, then real-time service reception is maintained, but non-real-time service processing capability is lost
Solution Approach 1:
The broadcast receiver is enhanced to perform multiple functions by integrating both real-time service reception and non-real-time service processing capabilities. The receiver can identify NRT services through signaling information and handle them using appropriate protocols (FLUTE, ALC/LCT, or DSM-CC), making a single device capable of diverse service types without requiring separate specialized equipment.
2Loss of information
If NRT service signaling information is added to broadcast streams, then NRT content identification is enabled, but processing complexity increases
Solution Approach 1:
The signaling information for NRT services is segmented and integrated into the existing broadcast stream structure. The signaling includes specific fields (service_type, delivery_method, protocol_type) that divide NRT service identification into discrete, manageable components, allowing receivers to process only the relevant portions needed for NRT service identification without handling entire broadcast streams differently.
3Adaptability or versatility
If multiple protocols (FLUTE, ALC/LCT, DSM-CC) are supported for NRT delivery, then delivery method flexibility is improved, but implementation difficulty increases
Solution Approach 1:
The receiver implements dynamic protocol selection based on the protocol_type field in the signaling information. Rather than statically configuring support for all protocols, the receiver dynamically activates the appropriate processing path (FLUTE, ALC/LCT, or DSM-CC) based on what is indicated in the broadcast signaling, allowing flexible adaptation to different delivery methods while simplifying implementation by only processing the active protocol at any given time.
Data Source
AI summary
A method of processing a non-real time (NRT) service in a broadcast receiver is disclosed where the method includes receiving signaling information including the NRT service information and access information which indicates files of a content item can be accessed by Internet, receiving File Delivery over Unidirectional Transport (FLUTE) files through a FLUTE session, wherein File Delivery Table (FDT) instance of the FLUTE session for each file belonging to the content item includes information for content location of the file, the information for content location including an Uniform Resource Locator (URL), and providing the NRT service using the files belonging to the content item, wherein the files are accessed through the Internet using the URL indicated in the information for content location of the file or accessed through a storage in the broadcast receiver.