WO2016003234A1 - 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 - Google Patents
멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 Download PDFInfo
- Publication number
- WO2016003234A1 WO2016003234A1 PCT/KR2015/006873 KR2015006873W WO2016003234A1 WO 2016003234 A1 WO2016003234 A1 WO 2016003234A1 KR 2015006873 W KR2015006873 W KR 2015006873W WO 2016003234 A1 WO2016003234 A1 WO 2016003234A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- value
- entity
- packet
- message
- transmitting
- Prior art date
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
- H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1864—ARQ related signaling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1896—ARQ related signaling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/637—Control signals issued by the client directed to the server or network components
- H04N21/6375—Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
- H04N21/6582—Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number
Definitions
- the present invention relates to a method and apparatus for transmitting and receiving information in a multimedia system.
- Moving picture experts group (MPEG) media transmission (MPT) technology which is one of technologies for transmitting information in a multimedia system, transmits and receives information using an automatic repeat request (ARQ) method.
- MPEG Moving picture experts group
- ARQ automatic repeat request
- a sending entity distinguishes whether or not ARQ is supported for each asset, but does not inform whether ARQ is supported as a receiving entity.
- the receiving entity does not know whether it can receive a reply when it re-requests the lost packets, or if it is for smooth service, the sending entity or ARQ server can send MMT packets for all assets for a certain time.
- the transmitting entity may also perform an operation of an ARQ server that stores and transmits a retransmission packet.
- the MMT ARQ message can be retransmitted with only one combination of Packet_ID and PACKET_SEQUENCE_NUM, which means that the retransmission request can be performed only in packet units.
- Packet_ID and PACKET_SEQUENCE_NUM which means that the retransmission request can be performed only in packet units.
- MPU media processing unit
- MFU media fragment unit
- sample and the like
- More useful data recovery may be possible if the desired level of media units can be requested.
- the transmitting entity 100 determines a retransmission delay time Dt value 101, and receives an ARQ configuration (AC) message including information related to the determined Dt value. Transmit to entity 200 (103). Then, when the receiving entity 200 receives the packet N-1 and the packet N + 1 from the transmitting entity 100 and does not receive the packet N (105 to 109), it calculates an Arrival_Deadline value (109). ) No additional operation is performed for packet reception during the calculated Arrival_Deadline value. The Arrival_Deadline value is calculated based on the Dt value and the ARQ feedback delay time Df value.
- the receiving entity 200 transmits an ARQ feedback (AF) message to the transmitting entity 100 for requesting retransmission of the packet N which has not been received (113).
- the AF message includes information related to an Arrival_Deadline value and information related to an ARQ feedback timestamp.
- the transmitting entity 100 checks information related to a Df value, a round trip time (RTT) value, and an Arrival_Deadline value from the received AF message (115 to 119), and determines whether the RTT value is smaller than the Arrival_Deadline value. Determine (121). When the RTT value is less than the Arrival_Deadline value, the transmitting entity 100 retransmits packet N (122). When the RTT value is not smaller than the Arrival_Deadline value, the transmitting entity 100 waits until the Arrival_Deadline value ends.
- RTT round trip time
- the conventional ARQ method described with reference to FIG. 1 transmits an Arrival_Deadline value from the receiving entity 200 to the transmitting entity 100, and when a packet requesting retransmission is not transmitted to the final receiving entity 200 during the Arrival_Deadline value, transmitting.
- the entity 100 gives up the response transmission itself.
- the Arrival_Deadline value is a value that can be known when the receiving entity 200 checks all the received packets and recovers the media, the receiving entity 200 may consume a lot of time and resources to derive the Arrival_Deadline value. do.
- the transmitting entity 100 abandons the response transmission, the receiving entity 200 does not recognize this, and there is a problem of waiting only until the Arrival_Deadline value ends.
- the expiration date information of asset delivery characteristic (ADC) information indicating individual transmission characteristic values of each asset is not provided, a method for solving this problem is required.
- ADC asset delivery characteristic
- MMT media data transmitted from a specific transmitting entity to a receiving entity are often transmitted not only as one asset but also as a combined unit of assets that are highly related to each other. Therefore, not only the control and management of the asset unit but also the network can easily manage the bundle delivery characteristics (BDC) information.
- the ADC information is provided in asset units, which are individual media. In this case, the discovery and management of ADC information is provided in asset units. Therefore, the MMT aware network entity (MANE) for the server / MMT is more than necessary. Information may be provided.
- bundle-to-bundle and bundle-in-bundle assets as well as bundle information, which is a bundle information of assets at a media level having a significant relevance, are provided. No relative priority information is given between the asset and the asset.
- One embodiment of the present invention provides a method and apparatus for transmitting and receiving information in a multimedia system.
- an embodiment of the present invention provides a method and apparatus for transmitting and receiving information based on an ARQ method in a multimedia system.
- an embodiment of the present invention provides a method and apparatus for configuring a bundle, which is a group of assets in a multimedia system, and transmitting and receiving information based on transmission characteristic information of each bundle.
- a method of transmitting a packet by a transmitting entity for retransmission of a packet may include a round trip time based on delay time values for receiving a specific message generated in each of the transmitting entity and the receiving entity. determining a round trip time (RTT) value, and determining whether to retransmit a packet for which retransmission is requested based on the RTT value.
- RTT round trip time
- a receiving entity receives information for packet retransmission by transmitting a retransmission message for requesting retransmission of a specific packet to a transmitting entity, and the transmitting entity and the receiving entity. If the round trip time (RTT) value determined based on the delay time values for the reception of a specific message generated in each of them is smaller than a preset delay time value, receiving the specific packet from the transmitting entity Include.
- RTT round trip time
- the apparatus for transmitting information for packet retransmission by a transmitting entity in a multimedia system may further include a round trip time based on delay time values for receiving a specific message generated in each of the transmitting entity and the receiving entity. and a processor for determining a round trip time (RTT) value and determining whether to retransmit a packet for which retransmission is requested based on the RTT value.
- RTT round trip time
- an apparatus for receiving a packet for information on packet retransmission by a receiving entity transmits a retransmission message requesting retransmission of a specific packet to a transmitting entity, and in each of the transmitting entity and the receiving entity.
- FIG. 1 is a diagram illustrating an example of applying an ARQ method in a conventional MMT system.
- FIG. 2 is a diagram showing the configuration of each node in the MMT system according to an embodiment of the present invention.
- FIG. 3 is a diagram illustrating a method of transmitting and receiving MMT system information according to a first embodiment of the present invention.
- FIG. 4 is a diagram illustrating a method of transmitting and receiving MMT system information according to a second embodiment of the present invention.
- FIG. 5 is a diagram illustrating a method of transmitting and receiving MMT system information according to a third embodiment of the present invention.
- FIG. 6 is a diagram illustrating a method of transmitting and receiving MMT system information according to a fourth embodiment of the present invention.
- FIG. 7 is a diagram illustrating a method of transmitting and receiving MMT system information according to a fifth embodiment of the present invention.
- FIG. 8 is a diagram illustrating a method of transmitting and receiving MMT system information according to a sixth embodiment of the present invention.
- FIG. 9 is a diagram illustrating a configuration of ADC information in the current MMT standard.
- FIG. 10 is a diagram illustrating a configuration of BDC information according to another embodiment of the present invention.
- FIG. 11 is a diagram showing the configuration of each node in the MMT system according to another embodiment of the present invention.
- FIG. 12 is a diagram illustrating a method for transmitting BDC information in a transmitting entity according to another embodiment of the present invention.
- the present invention indicates (1) whether the ARQ method can be used for each asset and the address of the ARQ server by explicitly distinguishing the MMT receiving entity, and (2) what factors the receiving entity receives when making an ARQ request.
- the hypothetical receiver buffer model (Hypothetical Receiver) is a message for managing the receiving entity buffer whether or not the receiving entity sends an ARQ request message.
- Buffer Model is determined by comparing the RTT value with fixed_end_to_end_delay or max_end_to_end_delay of the message, and (4) when making a Delay-Constrained ARQ request, whether the sending entity sends a response message for the requested packet from the receiving entity. Compare RTT value with fixed_end_to_end_delay or max_end_to_end_delay of HRBM message which is a message for buffer management It relates to an apparatus and method to set.
- an AC message is used to configure an ARQ operation of a receiving entity.
- the following parameter values are defined to use an AC message.
- ARQ_support_flag is a flag indicating whether ARQ can be used for each asset (packet_id).
- ARQ_support_flag indicates that a receiving entity can receive the packet from the ARQ server when there is a loss of a packet belonging to the packet_id.
- rtx_window_timeout 0 ms is not used without ARQ_support_flag, this means that the corresponding asset does not support packet retransmission.
- arq_server_address means the address of ARQ server that can receive packet retransmission when AF message is sent from receiving entity.
- arq_type indicates what type of request message can be sent when the receiving entity sends the AF message. From Table 3 below, in case of '00', a packet to be retransmitted can be indicated by using packet_counter of an MMT packet header, and in case of '01', a packet to be retransmitted by a combination of packet_id and packet_sequence_number of an MMT packet header Can indicate a packet.
- Table 1 below shows information included in an AC message according to an embodiment of the present invention.
- Valid values for the arq_typ field in Table 1 may be defined as shown in Table 3 below.
- the MMT receiving entity when the MMT receiving entity needs to retransmit the packet, it constructs an AF message and transmits it to the ARQ server.
- the AP message should be reconfigured as shown in Table 4 according to an embodiment of the present invention.
- valid values for the argument_type field may be defined as shown in Table 6 below, and valid values for the delay_constrained_ARQ_mode field may be defined as shown in Table 7 below.
- FIG. 2 illustrates a configuration of each node in an MMT system according to an embodiment of the present invention.
- a transmitting entity 210 which is a transmitting node of an MMT packet, a receiving entity 250 which is a receiving node of an MMT packet, and an ARQ server 230 storing and transmitting a retransmitting packet are included.
- the transmitting entity 210 may have a function of the ARQ server 230.
- the MMT packet generation and storage unit 213 included in the transmitting entity 210 is a module that MMT packetizes assets, and the HRBM information storage / management unit 211 generates, stores, and forwards HRBM information for receiving entity buffer management.
- the MMT packet transmitter 215 is a module for transmitting the generated MMT packet.
- the transmitting entity 210 performs an operation of transmitting and receiving information according to an embodiment of the present invention, and a detailed operation thereof will be described in detail with reference to FIGS. 3 to 8 below.
- the channel state measurement unit 231 included in the ARQ server 230 receives the AF message from the receiving entity 250 to determine whether the retransmitted packet can be delivered to the receiving entity within a meaningful time.
- the MMT packet storage unit 233 is a module that receives and copies / stores the packets in advance from the transmitting entity 210 in order to transmit a packet for which retransmission is requested from the receiving entity 250.
- the MMT packet retransmission determining unit 237 is a module for determining whether the retransmitted packet can be delivered to the receiving entity 250 within a meaningful time when receiving the AF message from the receiving entity 250.
- the module may be configured to determine max_end_to_end_delay or fixed_end_to_end_delay information by comparing the RTT with the receiving entity 250.
- the MMT packet transmitter 241 is a module for transmitting the generated MMT packet
- the AC setting unit 239 is a module for generating / storing / transmitting ARQ configuration information.
- the ARQ server 230 performs an operation for transmitting and receiving information according to an embodiment of the present invention, a detailed operation thereof will be described in detail with reference to Figures 3 to 8 below.
- the channel state measurement unit 251 included in the receiving entity 250 is a module for measuring an RTT with the ARQ server to determine whether a retransmitted packet can be received within a meaningful time when a packet retransmission is requested.
- the MMT packet retransmission request unit 255 is a module for transmitting an ARQ request when a lost packet is detected.
- the MMT packet retransmission request unit 255 compares the RTT of the HRBM information with the max_end_to_end_delay or fixed_end_to_end_delay information with the receiving entity 250 to mean a retransmitted packet.
- the module is characterized by determining whether it can be properly delivered to the receiving entity 250 within a predetermined time and, if necessary, determining whether to send the retransmission request message itself.
- the AC receiver 257 is a module that receives / stores ARQ configuration information
- the MMT packet receiver 261 is a module that receives the transmitted MMT packet.
- the MMT packet loss detector 259 is a module that detects whether the transmitted MMT packets are lost / received
- the HRBM information storage / management unit 253 is a module that receives and stores HRBM information for receiving entity buffer management.
- the receiving entity 250 performs an operation of transmitting and receiving information according to an embodiment of the present invention, a detailed operation thereof will be described in detail with reference to FIGS. 3 to 8 below.
- FIG. 2 shows detailed units included in each of the transmitting entity 210, the ARQ server 230, and the receiving entity 250, at least two of the detailed units shown in each device are integrated. Of course it can be implemented. In addition, the detailed units shown in each device may be implemented by one processor.
- a first embodiment of the present invention relates to a method of transmitting and receiving information when a receiving entity 250 determines whether to request retransmission for a lost packet.
- the transmitter 300 transmits a measurement configuration (MC) message to the receiving entity 250 (301). Then, the receiving entity 250 checks the time at which the MC message is received, and determines a propagation time D1 value for the packet from the transmitting entity 300 to the receiving entity 250 (303). A reception quality feedback (RQF) message including information related to the determined D1 value is transmitted to the transmitting entity 300 (305).
- MC measurement configuration
- RQF reception quality feedback
- the transmitting entity 300 determines an uplink delay time D2 value based on the information related to the D1 value included in the received RQF message (307).
- the D2 value may be determined based on the difference between Feedback_timestamp and timestamp.
- the transmitting entity 300 transmits an HRBM message including information related to the fixed_end_to_end_delay value to the receiving entity 250 (309).
- the receiving entity 250 checks the information related to the fixed_end_to_end_delay value included in the received HRBM message (311).
- the transmitting entity 300 generates an AC message including information related to the latest D2 value (3113), and repeatedly transmits the generated AC message to the receiving entity 250 (315).
- the receiving entity 250 checks the new D1 value from the received AC message (317), checks information related to the new D2 value included in the AC message (319), and determines the new RTT value (321).
- the new RTT value is determined based on the new D1 value and the new D2 value.
- a new RTT value is based on the fixed_end_to_end_delay value. It is determined whether to request retransmission (329). That is, the receiving entity 250 transmits an AF message for packet N when a new RTT value is shorter than the fixed_end_to_end_delay value (that is, when a retransmitted packet can be received within a limited time when requesting packet retransmission). In step 331, the packet N is retransmitted from the transmitting entity 300 (333).
- the receiving entity 250 does not request retransmission for the lost packet if the new RTT value is longer than the fixed_end_to_end_delay value (that is, if the retransmitted packet cannot be received within a limited time when the packet retransmission is requested). Do not.
- the transmitting entity 300 may or may not retransmit the requested packet according to an embodiment of the packet retransmission.
- the first embodiment of the present invention does not allow the transmitting entity 300 to determine whether the receiving entity 250 unconditionally performs and responds to the retransmission request once in the delay-constrained ARQ environment. If the entity 250 determines that the packet is not received within a limited time by comparing the information included in the HRBM message with the information related to the RTT value, the entity 250 may not transmit the retransmission request itself. In this case, as determined by the information related to the max_end_to_end_delay value or the fixed_end_to_end_delay value in the HRBM message as in the example of FIG. 3, since the receiving entity 250 does not need to check all received packets and recover the media, retransmission is performed. Requesting time and resources can be minimized. In addition, since the determination of the retransmission request is performed by the receiving entity 250, the waiting time for the unnecessary retransmission response may be reduced.
- FIG. 4 shows an information transmission and reception method in an MMT system according to a second embodiment of the present invention.
- the second embodiment of the present invention relates to a method for transmitting and receiving information when determining whether to request retransmission for a packet lost in the transmitting entity 300.
- the transmitting entity 300 measures an RTT value using an RQF message. It is about the case.
- the transmitting entity 300 checks the information related to the fixed_end_to_end_delay value included in the HRBM message (401). In addition, the transmitting entity 300 generates an MC message including a condition for transmitting the D1 value when the AR 109 transmits the ARQ request (403), and transmits the generated MC message to the receiving entity 250. send.
- the receiving entity 250 determines a D1 value based on the received MC message, and transmits an RQF message including information related to the D1 value to the transmitting entity 300 (409). Then, the transmitting entity 300 determines a D2 value based on the RQF message (411), and calculates an RTT value by summing the D1 value and the D2 value (413).
- the transmitting entity 300 transmits an AC message to the receiving entity 250, and the receiving entity 250 normally receives the packet N-1 and the packet N + 1 from the transmitting entity 300 and receives the packet N. Check that it did not (417 to 421).
- the receiving entity 250 determines a new D1 value based on the AC message (423), and determines whether to request packet retransmission for the packet N (425). If the receiving entity 250 determines to request packet retransmission, the receiving entity 250 transmits an RQF message including information related to the new D1 value to the transmitting entity 300 (425).
- the transmitting entity 300 determines a new D2 value based on the received RQF message (429), checks information related to the new D1 value included in the RQF message (431), and determines a new RTT value (431). 433).
- the transmitting entity 300 When the transmitting entity 300 receives an AF message requesting retransmission for packet N from the receiving entity 250 (435), it determines whether the new RTT value is smaller than the fixed_en_to_end_delay value (437). If the transmitting entity 300 is smaller than the fixed_en_to_end_delay value, the transmitting entity 300 retransmits the packet N to the receiving entity 250.
- the transmitting entity 300 may or may not retransmit the requested packet N according to an embodiment of the packet retransmission.
- the transmitting entity 300 since the transmitting entity 300 knows information related to the max_end_to_end_delay value and fixed_end_to_end_delay value in the HRBM message in advance, it responds to the retransmission when the retransmission request is received from the receiving entity 250. Rather than comparing the arrival_deadline value and the RTT value, it is possible to determine whether to retransmit by comparing the max_end_to_end_delay value or the fixed_end_to_end_delay value with the RTT value. As shown in step 437 of FIG.
- the transmitting entity 300 when the RTT value is smaller than the fixed_end_to_end_delay value, the transmitting entity 300 retransmits the packet because it means that the retransmitted packet can be delivered to the receiving entity 250 within a limited time.
- the RTT value is larger than the fixed_end_to_end_delay value, it means that the packet does not arrive within the limited time, and thus, the de-jittering buffer of the receiving entity 250 discards the received packet. There is no reception at the receiving entity 250. Therefore, when the RTT value is larger than the fixed_end_to_end_delay value, the transmitting entity 300 does not retransmit the packet.
- the transmitting entity 300 must use an RQF message to continuously check the latest RTT value.
- the receiving entity 250 may transmit various information such as channel status to the transmitting entity 300 through the MC message.
- the MMT communication system sets which information is reported in the MC message and includes the information in the RQF message. That is, the transmitting entity 300 needs to know information related to the latest RTT value so that the transmitting entity 300 determines whether to retransmit in Delay-constrained ARQ.
- a condition may be given to measurement_condition () in the MC message to transmit the RQF message to the transmitting entity 300.
- FIG. 5 illustrates an information transmission and reception method in an MMT system according to a third embodiment of the present invention.
- the third embodiment of the present invention relates to a method for transmitting and receiving information when determining whether to request retransmission for a lost packet in the transmitting entity 300.
- the third embodiment relates to the latest RTT value measured in the AF message in the transmitting entity 300. This is for the case where relevant information is inserted and transmitted.
- the transmitting entity 300 checks information related to the fixed_end_to_end_delay value included in the HRBM message (501).
- the transmitting entity 300 transmits the MC message to the receiving entity 250 (503).
- the receiving entity 250 determines a D1 value based on the MC message, and transmits an RQF message including information related to the D1 value to the transmitting entity 300.
- the transmitting entity 300 determines a D2 value based on the RQF message (509), and determines an RTT value using information related to the D1 value and the D2 value included in the RQF message (511).
- the receiving entity 250 receives the AC message from the transmitting entity 300 (513), and receives the packet N-1 and the packet N + 1 normally and confirms that the packet N has not been received (515 to 519). ).
- the receiving entity 250 transmits by designating which packet (eg, packet N) is requested to the transmitting entity 300 using the AF message.
- the transmitting entity 300 needs to know information related to the latest RTT value.
- the latest version of D1 ie, information related to the new D1 value
- the receiving entity 250 may update the D1 value by using a timestamp value in the packet header of other packets received from the transmitting entity 300 and attach it in the AF message for transmission.
- the receiving entity 250 transmits an AF message including information on the new D1 value to the transmitting entity 300.
- the transmitting entity 300 according to the third embodiment of the present invention checks the information on the new D1 value through the AF message (525).
- the transmitting entity 300 calculates a D2 value using the timestamp value of the packet header including the AF message, and calculates the most recent RTT value by adding the new D1 value and the D2 value (527).
- the transmitting entity 300 determines whether to retransmit the packet N by comparing the max_end_to_end_delay value or the fixed_end_to_end_delay value and the RTT value in the HRBM message (529).
- the RTT value and the max_end_to_end_delay may be compared, and when the FEC is not applied, the fixed_end_to_end_delay value and the RTT value may be compared.
- the transmitting entity 300 When the fixed_end_to_end_delay value is larger than the RTT value, the transmitting entity 300 indicates that the retransmitted packet can be safely received within a limited time when retransmitting the packet, and thus, the transmitting entity 300 retransmits the requested packet N. (531). On the other hand, when the transmitting entity 300 has a fixed_end_to_end_delay value smaller than the RTT value, it means that the retransmitted packet cannot be safely received within a limited time even if the packet is retransmitted, so that the transmitting entity 300 is configured for the requested packet N. Do not perform retransmission.
- the transmitting entity 300 may or may not retransmit the requested packet according to an embodiment of the packet retransmission.
- FIG. 6 shows a method of transmitting and receiving information in an MMT system according to a fourth embodiment of the present invention.
- the fourth embodiment of the present invention relates to a method for transmitting and receiving information when determining whether to request retransmission for a lost packet in the transmitting entity 300, and in particular, in the case where the receiving entity 250 transmits a periodic RQF message. .
- the transmitting entity 300 checks information related to the fixed_end_to_end_delay value included in the HRBM message (501).
- the transmitting entity 300 is configured to transmit a periodic RQF message in order to collect information related to the latest D1 value in the MC message (603).
- the set MC message is transmitted to the receiving entity 250 (605). That is, in the fourth embodiment of the present invention, information related to the latest RTT value should be able to be checked in order to determine whether the transmitting entity 300 responds to the packet retransmission during the delay-constrained ARQ.
- the transmitting entity 300 determines that Delay-constrained ARQ is necessary because of the real-time property of a particular asset
- the receiving entity 250 periodically sends an RQF message by setting a periodic value in the measurement_period value in the MC message. You can do that.
- the receiving entity 250 updates the D1 value using information related to the timestamp value in the packet header of other packets received from the transmitting entity 300 (607, 615), and sets the propagation_delay value in the RQF message to transmit the received entity. Periodic transmission to the entity 300 (609, 617).
- the transmitting entity 300 calculates the D2 value using the timestamp value of the packet header including the RQF message (611, 617), and calculates the RTT value using the D1 value and the D2 value (613, 621).
- the receiving entity 250 receives the AC message from the transmitting entity 300 (623), receives the packet N-1 and the packet N + 1 as normal, and confirms that the packet N has not been received (625 to 629). ). The receiving entity 250 transmits an AF message for requesting the packet N that has not been received to the transmitting entity 300 (631).
- the transmitting entity 300 compares the max_end_to_end_delay value or the fixed_end_to_end_delay value with the RTT value in the HRBM message to determine whether to retransmit the packet N (633). That is, when the fixed_end_to_end_delay value is larger than the RTT value, the transmitting entity 300 indicates that the retransmitted packet can be safely received within a limited time when the packet is retransmitted, so that the transmitting entity 300 receives the requested packet N. Retransmit (635). On the other hand, when the transmitting entity 300 has a fixed_end_to_end_delay value smaller than the RTT value, it means that the retransmitted packet cannot be safely received within a limited time even if the packet is retransmitted. Do not perform retransmission.
- the transmitting entity 300 may or may not retransmit the requested packet according to an embodiment of the packet retransmission.
- FIG. 7 illustrates a method of transmitting and receiving information in an MMT system according to a fifth embodiment of the present invention.
- the fifth embodiment of the present invention relates to an information transmission / reception method when the ARQ server 230 determines whether to request a retransmission for a lost packet when the separate ARQ server 230 exists.
- the ARQ server 230 for retransmission in the MMT may exist in a device that is physically separate from the transmitting entity 210.
- the transmitting entity 210 copies an MMT packet, transmits the MMT packet to the ARQ server 230, and transmits an HRBM message to the ARQ server 230 (701).
- the HRBM message includes at least one of information related to max_end_to_end_delay value and information related to fixed_end_to_end_delay value.
- the ARQ server 230 stores at least one of information related to max_end_to_end_delay value and information related to fixed_end_to_end_delay value included in the received HRBM message (703).
- the transmitting entity 210 specifies that the ARQ server 230 exists separately in the AC message (705), and transmits the AC message to the receiving entity 250 (707).
- the AC message may include information on the address of the separate ARQ server.
- the address of the separate ARQ server may be designated through arq_server_address as shown in Table 1.
- the server In order for the server to know and maintain the latest RTT value between the ARQ server and the receiving entity 250, an additional operation is required.
- the ARQ server 230 when there is a separate ARQ server 230 and the ARQ server 230 determines whether to retransmit, the ARQ server 230 is a transmission entity 210 to service itself Since it is not known yet, it is not possible to instruct the transmission of the latest RTT value through a voluntary MC / RQF message. Accordingly, the receiving entity 250 confirms that the packet N-1 and the packet N + 1 are normally received, and confirms that the packet N is not normally received (709 to 713).
- the receiving entity 250 is different from the address of the transmitting entity 210 and the address of the ARQ server 230, and is expected to request a Delay Constrained ARQ, and is used as the latest D1 value between the ARQ server 230 and the receiving entity 250. If there is no recent packet to be received, it is requested to send a random packet (it does not matter what information is included since it is for D1 measurement) to the ARQ server 230 to check the latest D1 value. (917).
- the receiving entity 250 receives an arbitrary packet from the ARQ server 230 (719) and determines a new D1 value (721).
- the receiving entity 250 transmits an AF message including information related to the new D1 value to the ARQ server 230 (723).
- the ARQ server 230 receives an AF message to determine a new D2 value (725), and determines a new RTT value based on the new D1 value and the new D2 value received through the AF message (727).
- the ARQ server 230 directly describes a method of directly determining a new RTT value.
- the transmitting entity 210 informs the receiving entity 250 of the address of the ARQ server 230 and the receiving entity 250 indicates that the address of the ARQ server 230 is different from that of the transmitting entity 210. If confirmed, registration for delay constrained ARQ operation may be performed through a separate message to the corresponding ARQ server.
- the ARQ server 230 measures information related to the RTT value in advance for the possibility of delay constrained ARQ operation for registered receiving entities.
- the ARQ server 230 compares the max_end_to_end_delay value or the fixed_end_to_end_delay value with the RTT value in the HRBM message to determine whether to retransmit the packet N (729). That is, when the fixed_end_to_end_delay value is larger than the RTT value, the ARQ server 230 means that the retransmitted packet can be safely received within a limited time when the packet is retransmitted, and thus the ARQ server 230 retransmits the requested packet N. (729).
- the ARQ server 230 If the fixed_end_to_end_delay value is smaller than the RTT value, it means that the retransmitted packet cannot be safely received within a limited time even if the packet is retransmitted, and thus the ARQ server 230 does not perform retransmission for the requested packet N.
- the transmitting entity 300 may or may not retransmit the requested packet N according to an embodiment of the packet retransmission.
- FIG. 8 illustrates an information transmission and reception method in an MMT system according to a sixth embodiment of the present invention.
- the sixth embodiment of the present invention relates to a method of transmitting and receiving information when a separate ARQ server 230 is present or not, when the receiving entity 250 determines whether to request retransmission for a lost packet.
- the receiving entity 250 determines whether to retransmit the packet, as shown in FIG. 8, between the ARQ server 230 and the receiving entity 250.
- the receiving entity 250 In order for the receiving entity 250 to continuously check the latest RTT value, it operates as follows.
- the transmitting entity 210 copies an MMT packet and transmits the MMT packet to the ARQ server 230 (801), and transmits an HRBM message to the receiving entity 250 (803).
- the receiving entity 250 then stores the fixed_end_to_end_delay value included in the HRBM message (805).
- the transmitting entity 210 specifies that an ARQ server 230 exists separately in an AC message (807), and transmits the AC message to the receiving entity 250 (809).
- the AC message may include information on the address of the separate ARQ server.
- the receiving entity 250 confirms that the packet N-1 and the packet N + 1 are normally received, and confirms that the packet N is not normally received (709 to 713). Since the receiving entity 250 does not know the RTT value, to receive the D2 value, the receiving entity 250 requests an AC message containing AC information, which is control information, instead of a general data packet through an AF message (817).
- the AF message requesting the AC message may be configured as shown in Tables 8 and 9 below.
- the ARQ server 230 determines a new D2 value based on the AF message (819), and generates an AC message including information related to the determined D2 value (821). At this time, the generated AC message is applied to the latest D2 value, which is channel information between the specific receiving entity 250 and the ARQ server 230 that the ARQ server 230 knows, as well as the ARQ configuration information as shown in Table 10 below. Include relevant information.
- the receiving entity 250 determines the new D1 value from the AC message (824), extracts the new D2 value (825), and determines the new RTT value (827).
- the receiving entity 250 determines whether to retransmit the packet N by comparing the max_end_to_end_delay value or the fixed_end_to_end_delay value and the RTT value in the HRBM message (829). That is, the receiving entity 250, when the fixed_end_to_end_delay value is larger than the RTT value, means that the retransmitted packet can be safely received within a limited time when the packet is retransmitted, the receiving entity 250 is a retransmission for the packet N
- the ARQ server 230 transmits the data to the ARQ server 230 (831). Then, the receiving entity 250 may retransmit the packet N from the transmitting entity 210 (833).
- the receiving entity 250 is If the fixed_end_to_end_delay value is smaller than the RTT value, it means that the retransmitted packet cannot be safely received within a limited time even if the packet is retransmitted, so that the receiving entity 250 does not perform retransmission for the requested packet N.
- the transmitting entity 300 may or may not retransmit the requested packet N according to an embodiment of the packet retransmission.
- a bundle which is a group of assets having a significant relevance among various assets constituting a package, is configured, and the ADC information of each asset is collected to collect BDCs of the bundles.
- the server or MANE transmits the relative priority between each bundle and the relative priority information between assets in each bundle. From this, the receiving entity can obtain hint information on which ones to select when it is necessary to stop the transmission of any asset based on the relative priority between each bundle and the relative priority information between assets in each bundle.
- the ADC information is information indicating a transmission characteristic of an asset (eg, video, audio, text, file, etc.) in the MPEG MMT standard, and has relationship and format (syntax and semantics) as shown in FIG. 9 and Table 11.
- the MANE can obtain the effect of bandwidth reduction by acquiring the trend of the future traffic transmission and the characteristic information value by using the ADC information. Knowing that you're arriving at speed has a number of advantages, including inferring how much buffer you need to get.
- the value of the loss_tolerance attribute may be expressed as shown in Table 13 below.
- the value of the class_of_service attribute may be expressed as shown in Table 14 below.
- the value of the class_of_service attribute may be expressed as shown in Table 15 below.
- FIG. 10 shows a configuration of a BDC according to another embodiment of the present invention.
- a scalable video including a base layer (Base layer (Asset 3)), an enhanced first layer (Enhancement layer 1 (Asset 2)), and an enhanced second layer (Enhancement layer 2 (Asset 1))
- Base layer Asset 3
- Enhancement layer 1 Asset 2
- SVC scalable video
- Audio content including mono (Asset 4), left (Asset 5), and light (Asset 6) channels.
- the transmitting entity may transmit various combinations of assets to the receiving entity in consideration of user preferences, network conditions, and terminal capacity.
- the transmitting entity sets the priority of the combination of assets, selects the priority according to the user's preference, the network situation, the capacity of the terminal, and transmits a bundle corresponding to the selected priority to the receiving entity.
- the MMT package has Bundle 1 including Asset 1 to Asset 6 having first priority, Bundle 2 including Asset 2 to Asset 4 having second priority, and third priority. It can consist of Bundle 3, including Asset 3 and Asset 4.
- the transmitting entity may transmit Bundle 1 including all assets from Asset1 to Asset6 to the receiving entity. And the sending entity can send Bundle 3 to the receiving entity if the network conditions are bad or the user is not a premium user.
- an MMT content is generally composed of several assets, and a collection of assets is selected to be played at a specific time.
- bundle units which are bundles of meaningful assets, not individual asset units, it may provide simpler and more efficient information to the network node or the receiving entity 250. Therefore, in the embodiment of the present invention, Syntax and Semantics for introducing the concept of Bundle and describing BDC information, which is the transmission characteristic information of the bundle, are defined as in Table 16 below.
- MMT_package_id means an ID of a corresponding package in which packages in the current BDC information are bundles in which package. There can be several assets in a package, and several bundles can be made up depending on how the assets are combined.
- the BDC information may be generated by the transmitting entity based on the ADC information, or may be provided by a package provider.
- Element_Asset_id is an Asset ID constituting the current BDC information.
- the BDC information includes ID list information of Assets constituting the bundle for each bundle which Asset is currently configured.
- Bundle_id is a delimiter to distinguish between bundles in a package.
- Intra_Bundle_Priority is an attribute value indicating the priority of assets in the bundle. This indicates the priority among assets that the content author considers important by the service provider or package provider that creates the package or bundle, and conveys the intention of the content provider to the sending entity, MANE, or receiving entity. It is a means. This allows dropping of MMTP packet units when the sending entity or MANE needs to stop or remove any asset transmission due to network congestion or user preference.However, priority between assets in the bundle is determined based on Intra_Bundle_Priority and the importance Depending on the specific asset itself, it can be dropped from the transfer. There may be many ways to express the priority, but it can be specified in any order defined by the content provider (eg, 0 is the highest priority, 12 is the lowest priority, etc.).
- Inter_Bundle_Priority is a property value that indicates the relative priority among several bundles in the current package. This indicates the priority among bundles in which a content provider is considered important by a service provider or a package provider that generates a package or bundle, and is a means of conveying the intention of the content provider to a transmitting entity, a MANE, or a receiving entity. This allows the sending entity or MANE to determine the priority between bundles based on Inter_Bundle_Priority when it needs to stop sending a bundle or switch to another bundle due to network congestion, user preference, etc. You can change this to send. There may be many ways to express the priority, but it can be specified in any order defined by the content provider (eg, 0 is the highest priority, 12 is the lowest priority, etc.).
- the value of the loss_tolerance attribute may be represented as shown in Table 18 below, and the value of the jitter_sensitivity property may be expressed as shown in Table 19 below, and the type of the bitstream attribute in the class_of_service field is shown in Table 20 below. Can be expressed as:
- FIG 11 shows the configuration of each node in an MMT system according to another embodiment of the present invention.
- a transmission entity 1110 which is an MMT packet transmission node
- a reception entity 1130 which is an MMT packet reception node
- a network node MANE 1150 such as a router switch
- the ADC signal generation / collection unit 1113 included in the transmitting entity 1110 collects ADC information including the traffic characteristic information of the media (ie, an asset) over time and makes it available to or received by the transmitting entity 1110.
- the BDC generator 1115 is a module that generates BDC information, which is transmission characteristic information about a specific bundle, from ADC information of respective assets constituting a specific bundle.
- the media transmission determiner 1117 determines whether the quality of the media data being transmitted should be changed according to changes in user preference, network congestion situation, and device capability.
- the media transmission determining unit 117 When the media transmission determining unit 117 needs to change the quality of the media data being transmitted, the media transmission determining unit 117 considers at least one of inter-bundle_priority and priority information between intra-bundle assets based on BDC information. Change the bundle to another bundle with a different quality, or stop the transmission of specific assets within a specific bundle. That is, the media transmission determiner 1117 is a module that determines an asset to be transmitted to enable adaptive transmission of media data.
- the network resource reservation processing unit 1111 is a module that processes a protocol (eg, RSVP) for reserving network resources for MMT traffic transmission as a separate protocol not defined in MMT.
- the MMT packet transmitter 1117 is a module that receives the MMT packet and transmits the MMT packet to the ADC detector 1157 or transmits the packet to the receiving entity 1150 as it is.
- a protocol eg, RSVP
- the BDC / ADC detector 1139 included in the MANE 1130 is a module that monitors MMT packets passing through the MANE 1130 and extracts a signaling message containing BDC / ADC information from the monitored MMT packets. For example, the MANE 1130 may determine whether the corresponding message contains BDC / ADC information based on the Type field of the MMT packet header and message_id information in the message. In addition, the BDC / ADC detection unit 1139 detects whether the BDC / ADC information needs to be updated and receives the updated BDC / ADC information if necessary, or also requests the BDC / ADC information to be sent to the transmitting entity 1110 if necessary. Module.
- the MMT packet receiving / transmitting / processing unit 1141 is a module that receives an MMT packet from a transmitting entity 1110 and delivers it to the receiving entity 1150.
- MMT packet reception / transmission / processing unit 1141 knows BDC information in advance and a packet drop is inevitably necessary due to network congestion, MANE performs an operation of dropping a specific packet or a specific asset based on the BDC information. Module.
- the dynamic resource management unit 1137 is a module that receives BDC / ADC information from the transmitting entity 1110 and efficiently applies the network resource request in consideration of its traffic characteristics.
- the dynamic resource management unit of the receiving entity 1150 It can be used as a reference when performing the sending entity 1110 and RSVP (eg, update and level).
- the BDC / ADC information may be used for buffer information to be secured by the receiving entity 1150.
- the network resource reservation processing unit 1131 is a module that processes a protocol (for example, RSVP) that reserves network resources for MMT traffic transmission as a separate protocol not defined in MMT.
- a protocol for example, RSVP
- the network resource allocator 1133 is a module that allocates network resources of its own (eg, a router) to specific traffic.
- the resource status monitoring unit 1135 is a module for identifying the resource usage status of the MANE 1130 currently being used.
- the dynamic resource management unit 1155 included in the receiving entity 1150 is a module that receives ADC information from the receiving entity 1110 and efficiently updates network resource requests in consideration of its traffic characteristics. ) Can be used as a reference when performing the transmitting entity 1110 and RSVP (ex. Update and level, etc.). In addition, the BDC / ADC information may be used for buffer information to be secured by the receiving entity 1150.
- the BDC / ADC detector 1157 is a module that monitors the received MMT packets and extracts a signaling message containing BDC / ADC information therefrom.
- the BDC / ADC detector 1157 is a BDC based on the Type field of the MMT packet header and message_id information in the message. It can be determined whether it contains / ADC information.
- the network resource reservation processing unit 1151 is a module for processing a protocol (eg, RSVP) for reserving network resources for MMT traffic transmission as a separate protocol not defined in MMT.
- the MMT packet receiver 1159 is a module that receives and processes an MMT packet from a transmitting entity 1110.
- FIG. 11 shows detailed units included in each of the transmitting entity 1110, the MANE 1130, and the receiving entity 1150, at least two of the detail units illustrated in each device are integrated. Of course it can be implemented. In addition, the detailed units shown in each device may be implemented by one processor.
- BDC information is generated as follows.
- BDC information of a specific bundle can be made by collecting the respective parameter values of ADC information, which are transmission characteristics of all assets belonging to the bundle.
- the transmission characteristic values (QoS descriptors and bitstream descriptors) of the corresponding bundle may generate ADC values of each asset using the following rule.
- the Leaky bucket model can be represented by the sustainable rate R and the buffer_size B. The values can be calculated as in Equation 1 and Equation 2 below.
- each parameter value of the bundle can be derived using the following parameter values.
- the bundle's sustainable_rate can be expressed as an arithmetic sum of the sustainable_rates of each asset, and Equation 1 and the size of the buffer required for a bundle can be expressed as Equation 2.
- R BDC R 1 + R 2 + R 3
- [Transmission_priority, Pr] can be calculated using Equation 4 below.
- the transmission priority of a bundle may be prioritized based on the priority of the largest asset among the assets of the bundle.
- Pr BDC max (Pr 1 , Pr 2 , Pr 3 )
- Delay_priority Dp can be calculated using Equation 5 below.
- the delay priority of a bundle may be prioritized based on the priority of the smallest asset among the delay priorities of the assets that make up the bundle.
- Dp BDC min (Dp 1 , Dp 2 , Dp 3 )
- Equation 6 [Class_of_service CS] can be calculated using Equation 6 below. At this time, if one of CS is VBR, the bundle is VBR. In Equation 6 below,
- Bidirectional_indicator can be calculated using Equation 7 below. At this time, if one of the BI is bidirectional, the bundle has a bi-direcional0.
- BI BDC (BI 1
- FIG. 12 illustrates a method of transmitting BDC information in a transmitting entity according to another embodiment of the present invention.
- the transmitting entity may effectively drop a packet by giving association information on relevant media to the nodes in consideration of user preference, network congestion, and device capability.
- the sending entity changes the quality of the media data being transmitted according to changes in user preferences, network congestion, and device capabilities (ie, high quality media data-> low quality media data, low quality media data-> high quality media data).
- the server / MANE / receiving entity 250, etc. needs to adapt to a situation such as stopping transmission of some assets, the bundle information according to an embodiment of the present invention may be used.
- the transmitting entity when the transmitting entity detects the necessity of providing adaptive quality for the media data being provided based on the current network congestion situation, the transmitting entity inter-bundle priority information (Inter_Bundle_Priority) included in the BDC information and the assets between the bundles. At least one of priority information Intra_Bundle_Priority is checked.
- the transmitting entity performs an operation of changing the bundle being transmitted to another bundle of different quality or stopping transmission of specific assets in a specific bundle based on at least one of the identified Inter_Bundle_Priority and Intra_Bundle_Priority. Accordingly, the receiving entity can receive a bundle according to the current network congestion situation and provide the optimal media data for the current situation.
- a transmitting entity performs adaptive transmission by removing a specific frame when media adaptive transmission is required in a network congestion situation.
- the transmitting entity performs adaptive transmission by dropping a specific frame uniformly on all assets.
- the transmitting entity it is also possible to selectively transmit or not transmit specific assets.
- the transmitting entity prioritizes the BDC information instead of simultaneously lowering both frame data of the video going to the main TV and the second screen through packet drops when network congestion occurs in N-screen broadcasting.
- the bundle itself may be changed from the information and the transmission characteristic information to a bundle of a specific low transmission rate according to the network congestion situation, or all of the less important assets transmitted to the second screen among the assets in the bundle may not be transmitted.
- the Inter_Bundle_Priority value is an attribute value indicating a relative priority among various bundles existing in the current package.
- the Inter_Bundle_Priority value indicates the priority among bundles that a content provider considers important by a service provider or a package provider that generates a package or bundle, and is a means of conveying the intention of the content provider to a transmitting entity, a MANE, or a receiving entity. This allows the sending entity or MANE to determine the priority between bundles based on the Inter_Bundle_Priority value when it needs to stop sending a bundle or change the transfer to another bundle due to network congestion and user preference, etc. Can be sent in bundles. There may be many ways to express the priority, but it can be specified in any order defined by the content provider (eg, 0 is the highest priority, 12 is the lowest priority, etc.).
- Intra_Bundle_Priority value is an attribute value representing the priority of Assets constituting BDC information in the bundle.
- the Intra_Bundle_Priority value indicates the priority among assets that the content provider considers to be important by a service provider or a package provider that generates a package or a bundle, and is a means of transmitting the intention of the content provider to a transmitting entity, a MANE, or a receiving entity. This allows dropping of MMTP packet units when the sending entity or MANE needs to stop or delete the transmission of any asset due to network congestion or user preference.However, the priority between assets in the bundle is determined based on the Intra_Bundle_Priority value. Depending on the importance, certain assets themselves can be dropped from the transfer. There may be many ways to express the priority, but it can be specified in any order defined by the content provider (eg, 0 is the highest priority, 12 is the lowest priority, etc.).
- the MMT flow transmitted from one transmitting entity to another receiving entity is configured as one bundle and transmission characteristics of the corresponding bundle can be known through BDC information.
- MANE uses the flow_label identifier in the MMT specification for per-flow QoS management of a specific flow.
- the flow_label may be defined as follows.
- flow_label (7bits)-This identifier identifies a flow and can be used when an application needs to temporarily reserve network resources during a session.
- One flow is defined as one or more bitstreams that require reservation of network resources using ADC information in the package. This may be assigned to any session in which a network number or a decoder resource is assigned a random number between 0 and 127.
- a specific flow_label may be represented as BDC information and used for resource reservation.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Multimedia (AREA)
- Databases & Information Systems (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Description
Claims (16)
- 멀티미디어 시스템에서 송신 엔터티가 패킷 재전송을 위한 정보를 송신하는 방법에 있어서,상기 송신 엔터티 및 수신 엔터티 각각에서 발생되는 특정 메시지의 수신에 대한 지연 시간 값들을 기반으로 라운드 트립 시간(round trip time: RTT) 값을 결정하는 과정과,상기 RTT 값을 기반으로 재전송이 요청된 패킷에 대한 재전송 여부를 결정하는 과정을 포함함을 특징으로 하는 정보 송신 방법.
- 제 1 항에 있어서, 상기 결정하는 과정은,상기 송신 엔터티로부터 상기 수신 엔터티로 전송된 패킷에 대한 제1 지연 시간 값을 포함하는 재전송 요청 메시지를 수신하는 과정과,상기 재전송 요청 메시지가 수신된 시간 값을 기반으로 업링크 전송에 대한 제2 지연 시간 값을 결정하는 과정과,상기 제1 지연 시간 값 및 상기 제2 지연 시간 값을 기반으로 상기 RTT 값을 결정하는 과정을 포함하는 정보 송신 방법.
- 제 2 항에 있어서, 상기 제1 지연 시간 값 및 상기 제2 지연 시간 값은 상기 특정 메시지가 송수신될 때마다 업데이트됨을 특징으로 하는 정보 송신 방법.
- 제 3 항에 있어서, 상기 결정된 RTT 값은 상기 제1 지연 시간 값 및 상기 제2 지연 시간 값의 업데이트에 따라 변경됨을 특징으로 하는 정보 송신 방법.
- 제 1 항에 있어서, 상기 재전송 여부를 결정하는 과정은,상기 RTT 값이 미리 설정된 지연 시간 값보다 작은 경우 상기 재전송이 요청된 패킷을 상기 수신 엔터티로 재전송하도록 결정하는 과정과,상기 RTT 값이 상기 미리 설정된 지연 시간 값보다 큰 경우 상기 재전송이 요청된 패킷을 상기 수신 엔터티로 재전송하지 않도록 결정하는 과정을 포함함을 특징으로 하는 정보 송신 방법.
- 제 5 항에 있어서, 상기 미리 설정된 지연 시간 값은,상기 수신 엔터티의 버퍼 관리를 위한 메시지를 기반으로 결정된 값임을 특징으로 하는 정보 송신 방법.
- 제 1 항에 있어서,상기 송신 엔터티의 주소에 대한 정보를 상기 수신 엔터티로 송신하는 과정을 더 포함함을 특징으로 하는 정보 송신 방법.
- 멀티미디어 시스템에서 수신 엔터티가 패킷 재전송을 위한 정보를 수신하는 방법에 있어서,송신 엔터티로 특정 패킷에 대한 재전송을 요청하는 재전송 메시지를 전송하는 과정과,상기 송신 엔터티 및 수신 엔터티 각각에서 발생되는 특정 메시지의 수신에 대한 지연 시간 값들을 기반으로 결정된 라운드 트립 시간(round trip time: RTT) 값이 미리 설정된 지연 시간 값보다 작은 경우, 상기 송신 엔터티로부터 상기 특정 패킷을 수신하는 과정을 포함하는 정보 수신 방법.
- 제 8 항에 있어서, 상기 재전송 메시지는,상기 송신 엔터티로부터 상기 수신 엔터티로 전송된 패킷에 대한 제1 지연 시간 값을 포함함을 특징으로 하는 정보 수신 방법.
- 제 9 항에 있어서, 상기 RTT 값은,상기 재전송 요청 메시지가 상기 송신 엔터티에서 수신된 시간 값을 기반으로 결정된 업링크 전송에 대한 제2 지연 시간 값과 상기 제1 지연 시간 값의 합에 의하여 결정됨을 특징으로 하는 정보 수신 방법.
- 제 10 항에 있어서, 상기 제1 지연 시간 값 및 상기 제2 지연 시간 값은 상기 특정 메시지가 송수신될 때마다 업데이트됨을 특징으로 하는 정보 수신 방법.
- 제 11 항에 있어서, 상기 RTT 값은 상기 제1 지연 시간 값 및 상기 제2 지연 시간 값의 업데이트에 따라 변경됨을 특징으로 하는 정보 수신 방법.
- 제 8 항에 있어서, 상기 RRT 값이 상기 미리 설정된 지연 시간 값보다 큰 경우 상기 송신 엔터티로부터 상기 특정 패킷이 수신되지 않음을 특징으로 하는 정보 수신 방법.
- 제 13 항에 있어서, 상기 미리 설정된 지연 시간 값은,상기 수신 엔터티의 버퍼 관리를 위한 메시지를 기반으로 결정된 값임을 특징으로 하는 정보 수신 방법.
- 청구항 1 내지 청구항 7 중 어느 하나의 방법을 수행하도록 구성되는 송신 엔터티.
- 청구항 8 내지 청구항 14 중 어느 하나의 방법을 수행하도록 구성되는 수신 엔터티.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15/323,612 US10498492B2 (en) | 2014-07-03 | 2015-07-03 | Method and device for receiving and transmitting information in multimedia system |
CN201580047294.6A CN106664440B (zh) | 2014-07-03 | 2015-07-03 | 用于在多媒体***中接收和发送信息的方法和设备 |
JP2017500081A JP6628785B2 (ja) | 2014-07-03 | 2015-07-03 | マルチメディアシステムにおける情報を送受信する方法及び装置 |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020140083199A KR102198701B1 (ko) | 2014-07-03 | 2014-07-03 | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 |
KR10-2014-0083199 | 2014-07-03 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016003234A1 true WO2016003234A1 (ko) | 2016-01-07 |
Family
ID=55019672
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/KR2015/006873 WO2016003234A1 (ko) | 2014-07-03 | 2015-07-03 | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 |
Country Status (5)
Country | Link |
---|---|
US (1) | US10498492B2 (ko) |
JP (1) | JP6628785B2 (ko) |
KR (1) | KR102198701B1 (ko) |
CN (1) | CN106664440B (ko) |
WO (1) | WO2016003234A1 (ko) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR102105656B1 (ko) * | 2014-01-09 | 2020-04-28 | 한국전자통신연구원 | Mmt 서비스의 패킷 재전송 방법 및 장치, 재전송 요청 방법 및 장치 |
CN110855402A (zh) * | 2016-09-30 | 2020-02-28 | 瞬已网络科技(上海)有限公司 | 一种网络实时视频传输方法及装置 |
CN109120383B (zh) * | 2017-06-26 | 2021-11-26 | 深圳市道通智能航空技术股份有限公司 | 无人机及其地面站、数据传输方法 |
US10686861B2 (en) * | 2018-10-02 | 2020-06-16 | Google Llc | Live stream connector |
CN111082899A (zh) * | 2018-10-19 | 2020-04-28 | 中兴通讯股份有限公司 | 一种传输方法、装置和*** |
CN114095796A (zh) * | 2020-07-30 | 2022-02-25 | ***通信集团终端有限公司 | 无效重传包减少方法、装置、设备及计算机存储介质 |
US11689777B2 (en) * | 2020-08-27 | 2023-06-27 | Dish Network Technologies India Private Limited | Pausing native media streaming for extended periods of time using dummy media segments |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20090076562A (ko) * | 2008-01-09 | 2009-07-13 | 삼성전자주식회사 | 전송 제어 프로토콜 기반의 패킷 전송 제어 방법 및 시스템 |
KR100987421B1 (ko) * | 2001-12-12 | 2010-10-13 | 소니 가부시키가이샤 | 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체 |
KR20110101403A (ko) * | 2010-03-08 | 2011-09-16 | 삼성전자주식회사 | 무선통신 시스템에서 기지국의 패킷 포워딩 장치 및 방법 |
KR20110112015A (ko) * | 2010-04-06 | 2011-10-12 | 삼성전자주식회사 | 이동통신 시스템에서 패킷 재전송 방법 및 장치 |
KR101203469B1 (ko) * | 2006-02-11 | 2012-11-21 | 삼성전자주식회사 | 패킷 네트워크에서 컷스루 방식으로 노드간 전파 지연 및거리를 정확하고 안전하게 측정하는 방법 및 상기 방법을수행하는 패킷 네트워크 노드 |
Family Cites Families (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS5983431A (ja) * | 1982-11-04 | 1984-05-14 | Omron Tateisi Electronics Co | デ−タ伝送制御方法 |
JPH09186679A (ja) * | 1995-12-27 | 1997-07-15 | Fuji Xerox Co Ltd | 通信装置 |
EP1018821A1 (en) * | 1999-01-08 | 2000-07-12 | TELEFONAKTIEBOLAGET L M ERICSSON (publ) | Communication device and method |
JP4015773B2 (ja) * | 1999-03-10 | 2007-11-28 | 松下電器産業株式会社 | 送受信装置 |
DE60020672T2 (de) * | 2000-03-02 | 2005-11-10 | Matsushita Electric Industrial Co., Ltd., Kadoma | Verfahren und Vorrichtung zur Wiederholung der Videodatenrahmen mit Prioritätsstufen |
JP2003008553A (ja) | 2001-06-22 | 2003-01-10 | Mitsubishi Electric Corp | 送信機、受信機、送受信機および通信システム |
US7145889B1 (en) * | 2002-03-28 | 2006-12-05 | Nortel Networks Limited | Efficient frame retransmission in a wireless communication environment |
US7719978B2 (en) * | 2003-09-12 | 2010-05-18 | Newsouth Innovations Pty Limited | Method for transmitting data over lossy packet-based communication networks |
KR20050044219A (ko) * | 2003-11-07 | 2005-05-12 | 삼성전자주식회사 | 광대역 무선 접속 통신 시스템에서 피드백을 위한 상향링크 자원 할당 방법 |
US7961700B2 (en) | 2005-04-28 | 2011-06-14 | Qualcomm Incorporated | Multi-carrier operation in data transmission systems |
KR100703287B1 (ko) * | 2005-07-20 | 2007-04-03 | 삼성전자주식회사 | 통신 시스템에서 자원 할당 정보 송수신 시스템 및 방법 |
US7672250B2 (en) | 2005-11-16 | 2010-03-02 | Via Telecom Co., Ltd. | Multi-carrier wireless communication access terminal and data transmission method |
KR100943590B1 (ko) * | 2006-04-14 | 2010-02-23 | 삼성전자주식회사 | 이동 통신 시스템에서 상태 보고의 송수신 방법 및 장치 |
JP5207416B2 (ja) * | 2007-06-22 | 2013-06-12 | アルカテル−ルーセント | Mbmsにおけるデータ再送信のための方法及びシステム |
KR101571145B1 (ko) * | 2007-10-23 | 2015-11-23 | 톰슨 라이센싱 | 무선 근거리 네트워크들에서의 신뢰 가능한 멀티캐스트를 위해 병합된 자동 반복 요청으로 적응 순방향 에러 정정을 하기 위한 방법 및 장치 |
US20090201794A1 (en) * | 2008-02-08 | 2009-08-13 | Qualcomm, Incorporated | Multiplexing devices over shared resources |
CN102057609B (zh) * | 2008-06-05 | 2014-12-03 | 诺基亚通信公司 | 无线通信网络中的接收单元和用于生成自动重传请求反馈消息的方法 |
EP2684402B1 (en) * | 2011-03-08 | 2020-02-05 | Panasonic Intellectual Property Corporation of America | Propagation delay difference reporting for multiple component carriers |
CN104335631B (zh) * | 2012-04-09 | 2018-06-19 | 瑞典爱立信有限公司 | 用于通过管理不确定测量时机来增强网络定位测量性能的方法和设备 |
US9137675B2 (en) * | 2012-06-13 | 2015-09-15 | All Purpose Networks LLC | Operational constraints in LTE TDD systems using RF agile beam forming techniques |
US8923464B2 (en) * | 2012-11-16 | 2014-12-30 | Qualcomm Incorporated | Methods and apparatus for enabling distributed frequency synchronization |
CN103354615B (zh) * | 2013-06-24 | 2015-04-15 | 西安交通大学 | 基于信号强度的直播视频数据传输差错控制方法 |
-
2014
- 2014-07-03 KR KR1020140083199A patent/KR102198701B1/ko active IP Right Grant
-
2015
- 2015-07-03 US US15/323,612 patent/US10498492B2/en active Active
- 2015-07-03 CN CN201580047294.6A patent/CN106664440B/zh active Active
- 2015-07-03 WO PCT/KR2015/006873 patent/WO2016003234A1/ko active Application Filing
- 2015-07-03 JP JP2017500081A patent/JP6628785B2/ja active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100987421B1 (ko) * | 2001-12-12 | 2010-10-13 | 소니 가부시키가이샤 | 데이터통신시스템, 데이터송신장치, 데이터수신장치, 데이터통신방법 및 컴퓨터가 판독가능한 기록 매체 |
KR101203469B1 (ko) * | 2006-02-11 | 2012-11-21 | 삼성전자주식회사 | 패킷 네트워크에서 컷스루 방식으로 노드간 전파 지연 및거리를 정확하고 안전하게 측정하는 방법 및 상기 방법을수행하는 패킷 네트워크 노드 |
KR20090076562A (ko) * | 2008-01-09 | 2009-07-13 | 삼성전자주식회사 | 전송 제어 프로토콜 기반의 패킷 전송 제어 방법 및 시스템 |
KR20110101403A (ko) * | 2010-03-08 | 2011-09-16 | 삼성전자주식회사 | 무선통신 시스템에서 기지국의 패킷 포워딩 장치 및 방법 |
KR20110112015A (ko) * | 2010-04-06 | 2011-10-12 | 삼성전자주식회사 | 이동통신 시스템에서 패킷 재전송 방법 및 장치 |
Also Published As
Publication number | Publication date |
---|---|
JP6628785B2 (ja) | 2020-01-15 |
CN106664440A (zh) | 2017-05-10 |
US20170141880A1 (en) | 2017-05-18 |
US10498492B2 (en) | 2019-12-03 |
JP2017526244A (ja) | 2017-09-07 |
KR102198701B1 (ko) | 2021-01-05 |
CN106664440B (zh) | 2020-01-10 |
KR20160004628A (ko) | 2016-01-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2016003234A1 (ko) | 멀티미디어 시스템에서 정보를 송수신하는 방법 및 장치 | |
CA2940754C (en) | Network packet latency management | |
US8208483B2 (en) | Ethernet switching | |
WO2012011746A2 (en) | Method and apparatus for providing multimedia streaming service | |
WO2015046960A1 (ko) | M2m 시스템에서 통지 메시지 전달 방법 및 이를 위한 장치 | |
WO2018074703A1 (ko) | 기지국장치 및 무선구간의 qos 제어방법 | |
US9007980B2 (en) | Multicast-unicast handoff services | |
WO2016036055A1 (ko) | 무선 통신 시스템에서 전송 제어를 위한 방법 및 장치 | |
WO2015030491A1 (ko) | 멀티 플로우 그룹핑에 기반한 대역폭 제공 방법 | |
WO2013112027A1 (ko) | 부호화된 미디어 데이터를 전송하는 장치에서의 네트워크 지터 추정 방법 | |
EP2652919B1 (en) | Method for group-based multicast with non-uniform receivers | |
US9013999B1 (en) | Method and apparatus for egress jitter pacer | |
US20090154349A1 (en) | Method and apparatus for managing traffic flow of forwarding entries through a virtual forwarding database of a network node | |
KR20140125274A (ko) | 방송 시스템에서 동적 큐 관리 방법 및 장치 | |
WO2015194906A1 (ko) | 이종망 기반 방송 서비스를 제공하는 방법 및 장치 | |
WO2015105384A1 (ko) | 멀티미디어 전송 시스템에서 미디어 데이터 관련 정보를 송신하는 방법 및 장치 | |
WO2013187667A1 (ko) | 멀티미디어 서비스를 위한 비트 에러율을 이용한 레이트 어댑테이션 방법 및 그 장치 | |
WO2011144100A2 (zh) | 多宽带网络网关下业务调度方法及装置 | |
US20130232231A1 (en) | Management of the transmission of data streams over multiple networks | |
JP2011119850A (ja) | 通信システムおよび帯域割当制御方法 | |
WO2015065003A1 (ko) | 서비스에 따른 트래픽 처리를 이용한 QoS 제어 방법 | |
WO2018101554A1 (ko) | 스트리밍 서비스 제공 방법 및 이를 위한 장치 | |
KR101132476B1 (ko) | Iptv 서비스의 품질 보장 기능을 가지는 네트워크 장치 | |
WO2011031097A2 (ko) | 복수의 세션 설정 방법 및 이를 이용하는 노드 | |
JP4133299B2 (ja) | 遅延時間抑制伝送方法およびシステムおよび遅延時間抑制伝送用ルータ |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 15814058 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15323612 Country of ref document: US |
|
ENP | Entry into the national phase |
Ref document number: 2017500081 Country of ref document: JP Kind code of ref document: A |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 15814058 Country of ref document: EP Kind code of ref document: A1 |