US20120300663A1 - Method and apparatus for retransmission decision making - Google Patents

Method and apparatus for retransmission decision making Download PDF

Info

Publication number
US20120300663A1
US20120300663A1 US13/575,646 US201013575646A US2012300663A1 US 20120300663 A1 US20120300663 A1 US 20120300663A1 US 201013575646 A US201013575646 A US 201013575646A US 2012300663 A1 US2012300663 A1 US 2012300663A1
Authority
US
United States
Prior art keywords
packet
network
data
statistics
receiver
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/575,646
Inventor
Xiuping Lu
Ishan Uday Mandrekar
Ramkumar Perumanam
Hang Liu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thomson Licensing SAS
Original Assignee
Thomson Licensing SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thomson Licensing SAS filed Critical Thomson Licensing SAS
Publication of US20120300663A1 publication Critical patent/US20120300663A1/en
Assigned to THOMSON LICENSING reassignment THOMSON LICENSING ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LU, XIUPING, LIU, HANG, MANDREKAR, ISHAN UDAY, PERUMANAM, RAMKUMAR
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829Arrangements specially adapted for the receiver end
    • H04L1/1835Buffer management
    • H04L1/1838Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • H04L1/1671Details of the supervisory signal the supervisory signal being transmitted together with control information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1874Buffer management
    • H04L1/1877Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video

Definitions

  • the present application relates to digital data networks in general and in particular, to a network monitor and data retransmission decision maker for reliable digital data transmission.
  • a multicast system as used herein is a system in which a server transmits the same data to multiple receivers simultaneously, where the receivers form a subset of all the receivers up to and including all of the receivers.
  • a broadcast system is a system in which a server transmits the same data to all of the receivers simultaneously. That is, a multicast system by definition can include a broadcast system.
  • Packet will, thus, be used herein to define any data formatting scheme known to one of ordinary skill in the art.
  • Video transmission or distribution in wireless networks is used by way of example herein of one application of a digital data network.
  • Video transmission in a wireless data network normally involves packet loss caused by channel error conditions such as interference, channel fading, collision, etc.
  • channel error conditions such as interference, channel fading, collision, etc.
  • the wireless link layer of the protocol stack may try to retransmit packets for a fixed number of times within a fixed time period. If these retransmissions are not successful, the packets are dropped by the wireless link layer.
  • IP network based video transmission typically delivers video packets to the destination (receiver; sometimes referred to as a client herein) using Real-time Transport Protocol (RTP) protocol that, in turn, uses either a reliable Transmission Control Protocol (TCP) transport protocol or a less reliable User Datagram Protocol (UDP) transport protocol.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • end-to-end acknowledgements are provided so that the protocol tries to send and/or recover media (audio, video, multimedia, . . .
  • TCP provides a sliding window mechanism for data flow control and reduces the packet transmission rate. TCP keeps retransmitting the lost packets until they are recovered.
  • Video transmission is an example of an application which occurs in real time and has a user viewing experience associated with the receipt and rendering of the data.
  • a latency or time constraint within which the packets have to be delivered or recovered should not impact the end user's viewing experience. Therefore, packet errors ought to be recovered within a limited time, otherwise the data may not be viewable.
  • TCP does not presently provide for control of packet recovery based on a time constraint. Consequently, using TCP as the transport protocol for wireless networks, could lead to a poor user viewing experience.
  • TCP requires positive acknowledgement for all the transmitted data packets.
  • the TCP uplink acknowledgements (from data receiver to data transmitter (sender) compete for the wireless bandwidth with downlink data traffic (from transmitter (sender) to receiver). If collisions occur among downlink and uplink transmissions, the collisions could lead to further throughput reduction.
  • PCT Application US/03/005,499 filed Oct. 7, 2009, discloses an efficient application-layer automatic repeat request retransmission method where data to be transmitted is buffered or cached at a module for implementing a reliable media protocol to recover lost data packets and aid, for example, in real-time streaming (such as video) data applications.
  • a real-time protocol packetization module 120 is provided at a real-time server 100, for example, for receiving a video digital data input 105.
  • Real-time protocol (RTP) packetization module 120 providing a streaming application is connected via, for example, a socket-like application programming interface (API) or interfaces 115 to the reliable media protocol module 130.
  • API application programming interface
  • the reliable media protocol module 130 accepts configuration data parameters 125 such as cache or buffer size, maximum time to wait for packet recovery and the like. These parameters are determined, for example, by the digital application, for example, telephony, audio, video or multimedia among other known applications.
  • the local buffer or cache memory 135 temporarily stores initially transmitted packets until it may be determined whether they need be retransmitted or discarded.
  • Server 100 transmits digital data by way of one of UDP/IP transmitter interface 140 or TCP/IP transmitter/receiver interface 145 and a digital data network interface, for example, an Ethernet/802.11 interface 150.
  • Initial real-time transmission may occur via initial transmit 160 to network 110 with real-time packets temporarily stored in cache/buffer 135, for example, awaiting receipt of Retransmit ACK/NACK control 155 or a predetermined time-out.
  • a method comprises monitoring a digital data network to collect network transport statistics, and deciding whether to retransmit a digital data packet to a receiver based on the collected network transport statistics.
  • an apparatus such as a digital data transmitter, comprises a digital data network monitor for collecting network transport statistics, and a retransmission decision maker for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and the collected network transport statistics.
  • an apparatus such as a digital data transmitter, comprises means, such as a network monitor, for collecting network transport statistics, and means, such as a retransmit decision maker, for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and collected network transport statistics.
  • an apparatus such as a digital data receiver, comprises a network monitor for collecting network statistics from the perspective of a receiver apparatus, and a network interface for outputting a control channel message including said collected network statistics.
  • an apparatus such as a digital data receiver, comprises means, such as a network monitor, for collecting network statistics from the perspective of a receiver apparatus, and means, such as a network interface, for outputting a control channel message including said collected network statistics
  • FIG. 1 is a schematic block diagram of a server having a reliable media protocol module and local cache or buffer for storing, for example, real-time packets awaiting a retransmission decision derived from FIG. 5 of related PCT Application US/19005,499 mentioned above.
  • FIG. 2A is a schematic block diagram of a server in accordance with the principles of the present invention showing a network abstraction-layer (NAL) header parser, a network monitor and a retransmit decision maker according to the present invention for monitoring a network interface for current network statistical data and providing an input to a reliable media protocol (RMP) module;
  • FIG. 2B is a schematic block diagram of an associated client having a network monitor for collecting receiver network-specific statistical data for transmission to the server of FIG. 2A in accordance with the principles of the present invention.
  • NAL network abstraction-layer
  • RMP reliable media protocol
  • FIG. 3A is a simplified block schematic drawing of a streaming server in accordance with the principles of the present invention having a NAL header parser for receiving an input from a scalable video coding (SVC) encoder, a network monitor and a retransmit decision maker.
  • FIG. 3A further depicts a streaming receiver for receiving digital data from the streaming server.
  • FIG. 3B is a block schematic drawing of the streaming server of FIG. 3A showing the NAL header parser receiving an input from a local MP4 file reader.
  • FIG. 3C shows the NAL header parser of FIG. 3A receiving an input from the network via a de-packetizer.
  • FIG. 4 shows a flowchart of operations at a sender side for abstraction-layer header parsing and network monitoring in accordance with the principles of the present invention, where the sender may be a transmitter, server or streaming server of FIG. 2A or FIG. 3 .
  • FIG. 4 further shows a data receiver and associated network monitoring operations where the receiver may be the client of FIG. 2B or the streaming receiver of FIG. 3 .
  • FIG. 5 shows an exemplary data contents representation format of a scalable video coder (SVC) Network Abstraction Layer (NAL) extension header for parsing in accordance with the principles of the present invention.
  • SVC scalable video coder
  • NAL Network Abstraction Layer
  • FIG. 6 shows an exemplary format of a real-time protocol (RTP) header in which priority data may be transmitted and from which network statistics may be calculated in accordance with aspects of the present invention.
  • RTP real-time protocol
  • FIG. 7 shows an exemplary format of an MPEG transport stream (TS) header, for example, MPEG-2, including a continuity counter (CC) field from which network monitoring statistics may be derived according to aspects of the present invention.
  • TS MPEG transport stream
  • CC continuity counter
  • FIG. 8 shows an exemplary format of a message including a transmission request and end-to-end packet loss rate from which network monitoring statistics may be derived according to aspects of the present invention.
  • FIG. 9 shows a first exemplary format of an ARQ request (NACK) packet from which network monitoring statistics may be derived according to aspects of the present invention.
  • FIG. 10 shows a second exemplary format of an RMP ARQ Request (NACK) packet in which network monitoring statistics may be transmitted and derived according to aspects of the present invention.
  • NACK RMP ARQ Request
  • the present invention is directed to a method and apparatus at a transmitter or sender for parsing an abstraction-layer header as an input to the real-time (for example, real-time protocol or RTP) packetization for a module for an improved reliable media protocol module per FIG's 2 A and 2 B and to a network monitor and retransmission decision maker of the transmitter/server 200 ( FIG. 2A ) which may utilize the parser priority output to selectively retransmit aata based on monitored network conditions, for example, packet loss rate.
  • real-time for example, real-time protocol or RTP
  • a network abstraction-layer for example, an H.264/AVC Network Abstraction Layer (NAL) of a real-time video encoder such as an MPEG-4 scalable video encoder (SVC) comprises a header that provides fields that may be parsed to determine digital data priority.
  • the NAL is network-friendly and may represent either video telephony, for example, video conversational applications and non-conversational applications such as storage of a down-loaded movie in memory, a broadcast or multicast application or streaming application or other non-conversational application.
  • the NAL for example, may be defined to represent a plurality of abstraction-layer units in the form of packets having one or more bytes.
  • the first byte of each NAL unit may be a header byte indicating the type of data of the unit while remaining bytes contain payload data of a type indicated by the NAL header.
  • an abstraction-layer header parser comprises parsing a scalable video encoder abstraction-layer header to obtain data from one of a plurality of fields.
  • the abstraction-layer header parser may operate, for example, on output digital video data of an MPEG 4 file reader or accept digital data from a network as received at a de-packetizer.
  • the abstraction-layer header parser may parse a DID field which represents an inter-layer coding dependency level of layer representation.
  • a QID field represents a quality level of medium grain scalability (MGS) layer representation.
  • a TID field represents a temporal level of layer representation.
  • One result of parsing an abstraction-layer header, comprising such fields, is to identify the layer that the following payload data is associated with.
  • One result of parsing an abstraction-layer header, comprising such fields is to identify the layer that the following payload data is associated with. Responsive to the identification of the payload data type, one may assign a different priority for each identified layer. For example, a base layer may receive a high priority for retransmission from buffer or cache memory since base layer is absolutely necessary for a complete decoding at a receiver. Responsive to the identification of the payload data type, the parser may assign a different priority for each identified layer for the following data.
  • a base layer may receive a high priority for retransmission from buffer or cache memory since base layer data is absolutely necessary for a complete decoding at a receiver.
  • An enhancement layer may be assigned a medium priority since enhancement layer data is necessary for decoding of a higher layer.
  • a high enhancement layer of payload data may be assigned a low priority.
  • the priority information may be represented in a “payload type” (PT) or similar field of a real-time protocol (RTP) header, if retransmission is called for at the transport layer, or in a type of service (TOS) field of an IP header.
  • PT payload type
  • RTP real-time protocol
  • TOS type of service
  • a type of service field may be also known in the art, by way of example, as a differential services (DS) field.
  • the first two bits are known as explicit congestion notification (ECN) bits, and the next six bits of a DS field byte are known as differential services code point (DSCP) bits.
  • ECN explicit congestion notification
  • DSCP differential services code point
  • Type of service will be generally used herein to refer to these and other formats for providing type of service data.
  • a real-time packet retransmission decision made by a reliable media protocol module may be thus layer-aware when modified to incorporate an abstraction-layer header parser and method according to one embodiment.
  • a network monitor for monitoring data network quality via a data network interface and, for example, collecting current network data statistics for input to a retransmit decision maker, for example, packet loss rate, available bandwidth, and round-trip delay.
  • the retransmit decision maker may provide an input to the reliable media protocol (RMP) module so that a decision on retransmission may be based on current network conditions according to the data network statistical data collected at the network monitor and selectively decide to retransmit a packet based on its priority and the monitored network conditions.
  • RMP reliable media protocol
  • a digital transmission method comprises parsing an abstraction-layer header of a digital data packet to obtain layer representation data, and assigning a priority to the digital data packet for the representation layer responsive to the parsing.
  • Obtaining layer representation data may comprise one or all of determining inter-layer coding dependency level, determining a quality level of grain scalability and determining temporal level of the layer representation.
  • the method may further comprise one of representing the priority level in a payload type field of a real-time transport packet header or in a type of service field of an internet protocol packet header.
  • an input to the abstraction-layer header parser may be received from a de-packetizer for receiving network data or received from a local server memory such as one associated with an MPEG file reader.
  • a digital data transmitter may comprise an abstraction-layer header parser to obtain layer representation data from a digital data packet and assign a priority to the layer representation data, a digital data monitor for collecting network transport statistics, and a retransmission decision maker for deciding whether to retransmit a digital data packet based on the assigned digital data packet priority and the collected network transport statistics.
  • an abstraction-layer header parser in a further embodiment may be a network abstraction-layer header parser for digital video data packet applications.
  • an abstraction-layer header parser, a data monitor and a retransmit decision maker of a server and a network monitor of a receiver provide for a highly reliable operation of RMP module 235 in making a decision whether or not to retransmit a packet that has been reported lost over a transmit control channel 255 as will be further described herein.
  • Video transmission or distribution in wireless networks typically use real-time transport protocol (RTP), motion picture expert group 2 transport stream (MPEG2TS) over UDP. Real-time video could be distributed from a single source to a single destination (unicast mode) or from a single source to multiple destinations (multicast mode).
  • RTP real-time transport protocol
  • MPEG2TS motion picture expert group 2 transport stream
  • the present invention provides an abstraction-layer header parsing functionality for an efficient application-layer based retransmission scheme, called reliable media protocol (RMP) herein, to recover packet losses to aid in reliable real-time streaming applications.
  • RMP reliable media protocol
  • the present invention also provides network monitoring capabilities at a transmitter and at a receiver side to improve packet retransmission decision making at server/transmitter 200 of FIG. 2A . Consequently, a network monitor 271 is provided at a receiver/client 201 of FIG. 2B .
  • RTP packetization 220 and a reliable media protocol (RMP) module 230 are assisted by the inclusion of NAL header parser 210 according to the principles of the present invention.
  • a network monitor 270 interfacing to network interface 250 collects current network statistics and, via retransmit decision maker 275 , improves the reliability of RMP module 230 .
  • NAL header parser 210 , network monitor 270 and retransmit decision maker 275 are highlighted in FIG. 2A to show that FIG. 2A is different from FIG. 1 as will be further explained below.
  • RMP module 230 transmits the regular unicast and multicast data or packets using UDP 240 via network interface 250 to transmit packets using initial transmit channel 260 to network 110 .
  • Data is initially stored in local cache 235 with a priority assigned by NAL header parser 210 via RTP packetization 220 .
  • an additional reliable TCP-based control channel 245 is established between the source (transmitter, sender) 200 of FIG. 2A and the destination (receiver, sink, client) 201 of FIG. 2B .
  • TCP/IP 245 requests the retransmission of and receives lost packets through network interface 250 via retransmit ACK/NACK control channel 255 to network 110 .
  • the transmitter (sender, server) 200 maintains a cache 235 of the most recent packets that were sent to its receivers/clients.
  • One or more receivers/clients 201 receive the data packets from the transmitter/server 200 and may detect sequence gaps in the received data packets using the sequence number field present in the RTP ( FIG. 6 ) or MPEG transport stream (TS) header ( FIG. 7 ). If the receiver 201 detects a sequence gap, the receiver 201 sends a request on the TCP-based control channel 255 for selective retransmission of the missing data packets.
  • the transmitter/server 200 receives a retransmission request from one or more of its receivers/clients 201 , it looks in its local cache 235 of most recent packets.
  • the sender/server 200 retransmits in unicast a copy of the packet to the receiver 201 on the TCP-based control channel 255 via network 110 . If the requested packet was not found in its local cache/buffer 235 , the sender 200 continues servicing the rest of the retransmission requests.
  • the receiver/client 201 maintains a delivery queue (buffer/cache) 236 to hold all of the received data packets from both data and control channels.
  • the receiver/client 201 also reorders the retransmitted packet into the correct sequence (position) within this queue and delivers the packets to the application in the proper order at the correct time, for example, a video player application 221 for display 206 .
  • receiver/client 201 maintains a configurable time window to wait for any retransmissions rather than waiting forever so that the packet delay and delay jitter can be kept within the application bounds.
  • receiver/client 201 is provided with a network monitor 271 according to one embodiment for collecting network statistics from the perspective of the receiver/client 201 for transmission via control channel 255 to transmitter/server 200 .
  • Network monitor 271 is shown highlighted in FIG. 2B to show the cooperation between network monitor 271 and network interface 251 for collecting and providing network statistics according to the present invention to transmitter/server 200 for improved retransmission decision making as will be further described herein.
  • the receiver/client 201 of FIG. 2B passes the rest of the received packets from the delivery queue to the application, for example, video player 221 and display 206 , if some of the retransmission replies for the lost packets are not received in time. If some of the retransmitted packets are received beyond the acceptable recovery time window they are discarded by the receiver. It should be noted that a video application can tolerate some data packet loss using error concealment technology in video decoding.
  • the reliable media protocol (RMP) scheme in the present invention operates via RMP module 230 , 231 between the real-time application/RTP/MPEG TS and UDP/TCP/IP through the assistance of parser 210 for prioritization and improved retransmit decision making with the assistance of network monitors 270 and 271 .
  • an abstraction-layer header parser for example, Network Abstraction Layer (NAL) header parser 210 operates on locally provided or network provided digital video data 205 .
  • NAL header parser 210 outputs a priority and the data for real-time protocol (RTP) packetization 220 .
  • NAL Network Abstraction Layer
  • a network monitor 270 recovers current network 110 statistics and outputs control data to retransmit decision maker 275 to aid RMP module 230 .
  • RMP module 230 will retransmit the high priority base layer data and not transmit the medium priority enhancement layer data in the face of an available bandwidth detected by network monitor 270 below a given threshold value.
  • a retransmission decision maker 275 may select a portion of the packets held in memory 235 for retransmission based on network monitor collected statistics, such as packet loss rate or other network conditions, and a priority assigned by NAL header parser 210 .
  • network monitor collected statistics such as packet loss rate or other network conditions
  • a priority assigned by NAL header parser 210 may be selected from a highly reliable media protocol (RMP) module 230 as will be further described in connection with a discussion of FIG. 4 .
  • RMP media protocol
  • a typical network interface 250 is shown between network 110 and RMP module 230 at server/transmitter 200 .
  • Examples of network interface modules are Ethernet cards, IEEE 802.11/WiFi cards that connect to the computer network 110 .
  • FIG. 2B shows the schematic of an exemplary implementation of a client device 201 .
  • the client may includes a video player/streaming application module 221 , a display 206 , a buffer (cache memory) 236 , a reliable media protocol (RMP) module 231 , a UDP/IP module 241 , a TCP/IP module 246 and a network interface 251 .
  • the network interface 251 may be, for example, an Ethernet interface or an IEEE 802.11 interface or other known network interface.
  • the network interface 251 receives all incoming messages. The messages arrive on different sockets/addresses.
  • Network monitor 271 collects current network statistics from the perspective of receiver/client 201 from network interface 251 and outputs a suitable control message on channel 255 reporting on collected statistics.
  • the network interface 251 can thus determine where to forward received messages from network 110 and output statistics data from network monitor 271 and messages from TCP/IP module 246 .
  • New incoming data packets are forwarded to the UDP/IP interface by the network interface module 251 .
  • Requests for retransmission of data packets and the retransmitted data packets are forwarded to the TCP/IP module 246 by the RMP module 231 .
  • the RMP module 231 determines if any of the received data packets have been corrupted and makes use of both UDP/IP and TCP/IP to orchestrate the packet recovery.
  • the RMP module 231 generates a retransmission request for any corrupted data packets.
  • the RMP module 231 then forwards the retransmission request to the TCP/IP module 246 for transmission over the network 110 .
  • any network statistics data collected by network monitor 271 are incorporated into the retransmission request for transmission over network 110 .
  • the RMP module 231 also stores the received packets in the local buffer 236 for reordering. Once the retransmitted packets are received from the TCP control channel via the TCP/IP module 246 , the RMP module 231 arranges the packets in the correct order.
  • the RMP 231 maintains a queue that is sorted on the sequence number and will reorder and insert packets into this buffer area/queue.
  • the RMP module 231 delivers the packets, for example, to the player/streaming application 221 for display 206 .
  • the RMP module 231 provides a socket-like application protocol interface (API) 216 for data passing and integration with the application. Note that some packets may not be recovered by the timeout of recovery window.
  • API application protocol interface
  • Data packets arriving after the expiration of the recovery window are discarded per FIG. 4 .
  • the streaming/player application 221 depacketizes and/or decodes the data and passes the data to the display/speaker 206 .
  • the incoming packets are stored in the RMP “Buffer area” and will be handed over, for example, to the application for rendering (display) 206 whenever an application requests a packet.
  • the box labeled “Config” 226 is a “Configuration Interface” to the RMP module 231 .
  • RMP module can be configured at the time of initialization to set parameters such as cache size, maximum time to wait for packet recovery etc.
  • a network monitor 271 may collect current network statistics at network monitor 271 from the perspective of receiver/client 201 via interface 251 and output the network experience of client/receiver 201 via control channel 255 to a server with which it is connected via digital data network 110 .
  • Such collected network statistics are output via interface 250 to network monitor 270 to supplement statistics gathered by network monitor 270 from the perspective of the transmitter/server of network 110 as discussed above.
  • Digital data network 110 may be any digital data network including but not limited to satellite networks, land-based wireless networks, fiber optic networks, coaxial cable networks, twisted pair networks, local area networks, wide area networks and other known digital data networks.
  • a typical network interface 251 is shown between network 110 and RMP module 231 at client/receiver 201 . Examples of network interface modules include Ethernet cards, IEEE 802.11/WiFi cards and the like that connect to the computer network 110 .
  • RMP module 230 first appears in FIG. 2 , is similar to reliable media protocol (RMP) module 130 of FIG. 1 , but is a different module from reliable media protocol (RMP) module 130 of FIG. 1 , because of the introduction of NAL Header Parser 210 and Network Monitor 270 and Retransmit Decision Maker 275 , all of which are not found in FIG. 1 .
  • RMP module 230 improves the operation of RMP module 230 and Retransmit Decision Maker 275 of FIG. 2A .
  • Some of the advantages of parser 210 , network monitors 270 and 271 and retransmit decision maker 275 have been described above but will be further described in connection with the discussion of FIGS. 3 and 4 below.
  • FIG. 3 provides a direct representation of NAL abstraction-layer header parser 210 , network monitor 270 and retransmit decision maker 275 of a streaming server/transmitter with reference to transmission to one or more streaming receivers connected via network 110 .
  • a scalable video coder (SVC) encoder 300 which may be located at the streaming server or remotely from it.
  • a scalable video coder (SVC) provides temporal or frame rate scalability, spatial or picture size scalability (video is, for example, coded at multiple resolutions and aspect ratios) and signal-to-noise ratio (SNR) or quality/fidelity scalability as will be described further herein.
  • NAL header parser 210 may be an H.264 compliant AVC Network Abstraction Layer (NAL) header parser or other abstraction-layer header parser with similar functionality as will be further described in connection with FIG. 4 .
  • NAL header parser 210 may receive an input from local memory store, for example, an MP-4 file reader 302 .
  • An exemplary streaming server embodiment may be a streaming server for providing IP television channel or movie services.
  • FIG. 3C there is shown a de-packetizer 304 for receiving, for example, streaming video from the network 110 and outputting the received packets to NAL header parser 210 .
  • An exemplary video application of the streaming server of FIG. 3C may be video telephony where the depicted streaming server is one server in a network path from one video communications terminal to another.
  • the NAL header parser 210 may provide a packet/frame priority via packetizer 310 to local cache 235 .
  • parser 210 outputs parser data and priority to packetizer 310 .
  • Per path 312 a copy is placed in local cache 235 and per path 314 , the packetizer sends packet data to depacketizer 320 of streaming receiver.
  • Network monitor 270 provides network transport condition data to retransmission decision maker 275 for selectively deciding on whether or not to retransmit a packet/frame stored in local cache 235 for retransmission over path 316 via network 110 to de-packetizer 320 .
  • Path 316 is used for retransmission of selected packets according to transport conditions and parser assigned priority.
  • the server/transmitter of FIG. 3 obtains data, for example, from a local file, per FIG. 3B , file reader 302 , or receives data from a network interface, for example, from network 110 and de-packetizer 304 of FIG. 3C .
  • the received data is provided to block 410 which represents the abstraction-layer header parser 210 of FIGS. 2A and 3 .
  • a typical abstraction-layer header for example, an SVC NAL extension header, providing fields to be parsed.
  • the abstraction-layer header parser 410 may parse a DID field shown appearing at positions 1 - 3 of the second byte (BYTE 1 ) which represents an inter-layer coding dependency of layer representation or level of spatial/resolution scalability.
  • a QID field at, for example, positions 4 - 7 of the second byte (BYTE 1 ) may follow and represents a quality level of medium grain scalability (MGS) layer representation.
  • a TID field for example, at positions 0 - 2 of the third byte (BYTE 2 ), represents a temporal level of layer representation.
  • a parser at parser block 410 of FIG. 4 may assign a different priority for each identified layer for following data: for example, a low, medium and high priority. More than three levels of priority may be employed in alternative embodiments. For example, a base layer may receive a high priority for retransmission from buffer or cache memory since base layer is absolutely necessary for a complete decoding at a receiver. An enhancement layer may be assigned a medium priority since enhancement layer data is necessary for decoding of a higher layer. An SVC-encoded stream of digital data may comprise a base layer and one enhancement layer. On the other hand, a second or more enhancement layers may be provided for even greater picture quality enjoyment and, so, a higher enhancement layer may be assigned a low priority in cache 235 for associated payload data.
  • the parser 410 can identify the base layer NAL units based on its DID field and assign the base layer a higher priority.
  • the enhancement layer may be assigned a lower priority (to provide the higher resolution).
  • the base layer is assigned the higher priority than the enhancement layer in this example.
  • the output priority level may be indicated in a payload type (PT) field of an RTP header shown in FIG. 6 at positions 9 - 15 .
  • the priority information may also be represented in a similar field of a real-time protocol (RTP) header, if retransmission is called for at the transport layer, or in a type of service (TOS) field of an IP header.
  • RTP real-time protocol
  • TOS type of service
  • the packet is received 460 and the receiver determines at 465 whether an expected packet is lost (Yes) or not (No). If lost (Yes), then at 485 , a retransmit request is sent, and a recovery timer of a receiver is set via the control channel 255 of FIG. 2B back to the sender/transmitter/server 200 . If no, then at 490 , the received packet is placed in proper order in a receiving buffer, for example, for a display function 206 at the receiver/client 201 .
  • a network monitor function 405 is actuated and the received retransmit request is then processed.
  • an end-to-end packet loss rate at a given time may be determined at a network monitor 271 as a current network 110 condition from the receiver side.
  • the current network condition for example, an end-to-end packet loss rate, is provided with the retransmit request as an output of 405 to retransmission decision maker 415 .
  • An exemplary application of a network monitor 405 may be where the sender/server is on a wired network 110 , for example, a set-top box (cable or satellite) or home gateway and the receiver is a mobile device or personal computer that is associated with a wireless access point AP.
  • An intermediate node/wireless access point (AP/router) may report the network and wireless channel conditions to the sender.
  • a real-time packet retransmission decision made by a reliable media protocol (RMP) module 230 may be thus layer-aware when modified to incorporate an abstraction-layer header parser and method according to one embodiment.
  • RMP reliable media protocol
  • Retransmission decision maker 415 questions whether, for example, the current end-to-end transmit packet loss rate is high, meaning whether it is above a threshold level set in memory of the RMP module 230 . If the answer is YES, then, at 445 , lower priority packets are dropped, and only higher priority packets are recovered from cache/buffer 430 and retransmitted.
  • Other measures of transport conditions besides packet loss rate may be available bandwidth (for example, the lowest available bandwidth in an end-to-end path) and round-trip delay (a longer round-trip delay may require the time-out of a packet held in cache/buffer 235 for retransmission). Each of these, including available bandwidth, may be compared with an associated threshold level set in memory for deciding on packet retransmission.
  • One or more may be employed in making the retransmission decision as well as packet priority set by parsing 410 . If the answer is returned NO, at 435 , all requested packets are retransmitted from cache/buffer 430 via “send the packet” 450 and network 110 .
  • the retransmitted packet is received at 460 and recognized as a retransmitted packet at 470 .
  • the time of receipt is examined at 475 .
  • the question is asked: Retransmit late? If the retransmitted packet is received too late, that is, the program viewing experience has already moved on to a next frame, then, the retransmit packet is discarded at 480 . On the other hand, if the retransmit packet is not late, (i.e., the answer is NO), the retransmit packet is placed in order in a receiving buffer for display at 490 .
  • the RMP method of the present invention may be implemented in a flexible software library, hardware, firmware, any computer or processor, an application specific integrated circuit (ASIC), a reduced instruction set computer (RISC), a field programmable gate array (FPGA) or an combination thereof.
  • the RMP method of the present invention uses socket-like user-space APIs and underlying transport means for easy integration with streaming server and player applications.
  • the RMP method of the present invention is transparent to the streaming applications that it supports.
  • the UDP data channel and the TCP control channel are internally maintained.
  • the RMP method of the present invention is extensible to support other error recovery schemes such as FEC and hybrid ARQ.
  • the network monitor function 405 of the present invention will now be described further with reference to FIGS. 6 , 7 and 8 .
  • One possible approach is shown in FIG. 6 where the network monitor 271 , for example, may detect a sequence gap from a sequence number, positions 6 - 1 of first line.
  • Another approach is to utilize a continuity counter (CC) field of an MPEG-2 transport stream header of one byte as seen in FIG. 7 .
  • CC continuity counter
  • the exemplary format of the message for sending statistics collected by a network monitor 271 of a receiver/client 201 of FIG. 2B to server/transmitter 200 of FIG. 2A is shown in FIG. 8 .
  • the message format may be similar to an RTP Control Protocol (RTCP) receiver report (RR) message.
  • RTCP RTP Control Protocol
  • RR receiver report
  • one may provide a “fraction lost” field, for example, at positions 0 - 7 of line 4 .
  • Other relevant data may be provided such as a cumulative number of packets lost which may be compared with a previously received cumulative number of packets lost received on the same channel. The difference provides a number of packets lost within an interval defined by the time between successful receipt of successive messages.
  • FIG. 9 provides a format for a sender/server/transmitter obtaining network packet loss through the retransmission requests received from the receiver/client 201 .
  • a network monitor function 405 of FIG. 4 calculates a number of lost packets from the fields “Base sequence # of starting packet” and “offset for ending packet.”
  • the RMP ARQ request (NACK) packet of FIG. 10 provides a base sequence number which can be stored and compared with subsequently received base sequence numbers. The depicted base sequence number and the bitmap indicate the sequence of the packets that the receiver requests to be retransmitted.
  • Yet another approach to determining network transport conditions is to monitor the lower layer, for example, network/MAC/PHY level transmission statistics to estimate the channel conditions and available bandwidth.
  • the RMP scheme of the present invention makes efficient use of the bandwidth since only the lost media packets are requested and retransmitted on the control channel with low overhead.
  • the lost packet requests serve as NACKs (Negative Acknowledgements) and also provide feedback to the sender. It can provide high reliability under widely different channel conditions because a lost packet can be retransmitted multiple times within the recovery time window.
  • the RMP scheme of the present invention enforces the application's latency constraint by having a maximum wait time (i.e., a recovery window) for retransmissions and thus operates on the best effort delivery model within the given time constraint.
  • the present invention can also be applied to transmission of audio, for example, telephony, and other real-time multimedia streaming applications.
  • the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof.
  • the present invention is implemented as a combination of hardware and software.
  • the software is preferably implemented as an application program tangibly embodied on a program storage device.
  • the application program may be uploaded to, and executed by, a machine comprising any suitable architecture.
  • the machine is implemented on a computer platform having hardware—such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s).
  • the computer platform also includes an operating system and microinstruction code.
  • various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system.
  • various other peripheral devices may be connected to the computer platform, such as an additional data storage device and a printing device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Communication Control (AREA)

Abstract

A method and apparatus are described including parsing an abstraction-layer header and assigning a priority to a packet to be transmitted. A network monitor of a transmitter is connected between a network interface and a retransmission decision maker for deciding which packets to retransmit, for example, based on the assigned priority and collected network statistics or conditions, for example, packet loss rate. A network monitor may also be provided at a receiver for collecting current network statistics such as cumulative number of packets lost and for providing such statistics to a transmitter. The method further includes buffering the data to be transmitted along with the assigned priority, transmitting data retrieved from a buffer via a datagram protocol, receiving a request for retransmission of data, determining if the requested data is in the buffer and retransmitting the requested data via a protocol that provides end-to-end acknowledgement of data and error recovery.

Description

  • This application is related to the following co-pending, commonly owned, U.S. patent applications: (1) Ser. No. ______ entitled AN EFFICIENT APPLICATION-LAYER AUTOMATIC REPEAT REQUEST (ARQ) RETRANSMISSION SCHEME FOR RELIABLE REAL-TIME STREAMING IN WIRELESS NETWORKS filed on Oct. 7, 2009 as an international patent application (Filing No. PCT/US09/005,499, Thomson Docket No. PU090136) and (2) Ser. No. ______ entitled A METHOD AND APPARATUS FOR PARSING A NETWORK ABSTRACTON-LAYER FOR RELIABLE DATA COMMUNICATION filed on ______ as an international patent application (Filing No. ______, Thomson Docket No. PU090157).
  • The present application relates to digital data networks in general and in particular, to a network monitor and data retransmission decision maker for reliable digital data transmission.
  • In multicast or broadcast applications, data are typically transmitted from a server to multiple receivers over wired and/or wireless networks. A multicast system as used herein is a system in which a server transmits the same data to multiple receivers simultaneously, where the receivers form a subset of all the receivers up to and including all of the receivers. A broadcast system is a system in which a server transmits the same data to all of the receivers simultaneously. That is, a multicast system by definition can include a broadcast system.
  • Data is usually formatted into packets and/or frames for transmission. That is, packets and/or frames are data formatting schemes. As used herein data can be formatted into any convenient format for transmission including packets and/or frames. “Packet” will, thus, be used herein to define any data formatting scheme known to one of ordinary skill in the art.
  • Video transmission or distribution in wireless networks is used by way of example herein of one application of a digital data network. Video transmission in a wireless data network normally involves packet loss caused by channel error conditions such as interference, channel fading, collision, etc. When such channel error conditions occur, the wireless link layer of the protocol stack may try to retransmit packets for a fixed number of times within a fixed time period. If these retransmissions are not successful, the packets are dropped by the wireless link layer. Internet Protocol (IP) network based video transmission typically delivers video packets to the destination (receiver; sometimes referred to as a client herein) using Real-time Transport Protocol (RTP) protocol that, in turn, uses either a reliable Transmission Control Protocol (TCP) transport protocol or a less reliable User Datagram Protocol (UDP) transport protocol. When the less reliable UDP protocol is used, for example, the protocol does not provide a means to detect out-of-order packets or recover lost packets and leaves the responsibility to an application to recover packet delivery errors. In contrast, when TCP protocol is used, end-to-end acknowledgements are provided so that the protocol tries to send and/or recover media (audio, video, multimedia, . . . ) packets (data) strictly in the order in which the packets are to be handled by the application. When packet errors are detected, TCP provides a sliding window mechanism for data flow control and reduces the packet transmission rate. TCP keeps retransmitting the lost packets until they are recovered.
  • Video transmission is an example of an application which occurs in real time and has a user viewing experience associated with the receipt and rendering of the data. A latency or time constraint within which the packets have to be delivered or recovered should not impact the end user's viewing experience. Therefore, packet errors ought to be recovered within a limited time, otherwise the data may not be viewable. TCP does not presently provide for control of packet recovery based on a time constraint. Consequently, using TCP as the transport protocol for wireless networks, could lead to a poor user viewing experience. Furthermore, TCP requires positive acknowledgement for all the transmitted data packets. The TCP uplink acknowledgements (from data receiver to data transmitter (sender) compete for the wireless bandwidth with downlink data traffic (from transmitter (sender) to receiver). If collisions occur among downlink and uplink transmissions, the collisions could lead to further throughput reduction.
  • PCT Application US/09/005,499, filed Oct. 7, 2009, discloses an efficient application-layer automatic repeat request retransmission method where data to be transmitted is buffered or cached at a module for implementing a reliable media protocol to recover lost data packets and aid, for example, in real-time streaming (such as video) data applications. Referring briefly to FIG. 1 (derived from FIG. 5 of PCT Application US/09/005,499 mentioned above), a real-time protocol packetization module 120 is provided at a real-time server 100, for example, for receiving a video digital data input 105. Real-time protocol (RTP) packetization module 120 providing a streaming application is connected via, for example, a socket-like application programming interface (API) or interfaces 115 to the reliable media protocol module 130. The reliable media protocol module 130 accepts configuration data parameters 125 such as cache or buffer size, maximum time to wait for packet recovery and the like. These parameters are determined, for example, by the digital application, for example, telephony, audio, video or multimedia among other known applications. The local buffer or cache memory 135 temporarily stores initially transmitted packets until it may be determined whether they need be retransmitted or discarded. Server 100 transmits digital data by way of one of UDP/IP transmitter interface 140 or TCP/IP transmitter/receiver interface 145 and a digital data network interface, for example, an Ethernet/802.11 interface 150. Initial real-time transmission may occur via initial transmit 160 to network 110 with real-time packets temporarily stored in cache/buffer 135, for example, awaiting receipt of Retransmit ACK/NACK control 155 or a predetermined time-out.
  • It would be advantageous to have an efficient method and apparatus to add further reliability to such a reliable media protocol based real-time data transmission system such as the one disclosed in the foregoing PCT Application US/09/005,499. The present invention addresses these and/or other issues.
  • In accordance with an aspect of the present invention, a method is disclosed. According to an exemplary embodiment, the method comprises monitoring a digital data network to collect network transport statistics, and deciding whether to retransmit a digital data packet to a receiver based on the collected network transport statistics.
  • In accordance with another aspect of the present invention, an apparatus is disclosed. According to an exemplary embodiment, an apparatus, such as a digital data transmitter, comprises a digital data network monitor for collecting network transport statistics, and a retransmission decision maker for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and the collected network transport statistics.
  • In accordance with another aspect of the present invention, an apparatus is disclosed. According to an exemplary embodiment, an apparatus, such as a digital data transmitter, comprises means, such as a network monitor, for collecting network transport statistics, and means, such as a retransmit decision maker, for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and collected network transport statistics.
  • In accordance with another aspect of the present invention, an apparatus is disclosed. According to an exemplary embodiment, an apparatus, such as a digital data receiver, comprises a network monitor for collecting network statistics from the perspective of a receiver apparatus, and a network interface for outputting a control channel message including said collected network statistics.
  • In accordance with another aspect of the present invention, an apparatus is disclosed. According to an exemplary embodiment, an apparatus, such as a digital data receiver, comprises means, such as a network monitor, for collecting network statistics from the perspective of a receiver apparatus, and means, such as a network interface, for outputting a control channel message including said collected network statistics
  • The above-mentioned and other features and advantages of this invention, and the manner of attaining them, will become more apparent and the invention will be better understood by reference to the following description of embodiments of the invention taken in conjunction with the accompanying drawings, wherein:
  • FIG. 1 is a schematic block diagram of a server having a reliable media protocol module and local cache or buffer for storing, for example, real-time packets awaiting a retransmission decision derived from FIG. 5 of related PCT Application US/09/005,499 mentioned above.
  • FIG. 2A is a schematic block diagram of a server in accordance with the principles of the present invention showing a network abstraction-layer (NAL) header parser, a network monitor and a retransmit decision maker according to the present invention for monitoring a network interface for current network statistical data and providing an input to a reliable media protocol (RMP) module; FIG. 2B is a schematic block diagram of an associated client having a network monitor for collecting receiver network-specific statistical data for transmission to the server of FIG. 2A in accordance with the principles of the present invention.
  • FIG. 3A is a simplified block schematic drawing of a streaming server in accordance with the principles of the present invention having a NAL header parser for receiving an input from a scalable video coding (SVC) encoder, a network monitor and a retransmit decision maker. FIG. 3A further depicts a streaming receiver for receiving digital data from the streaming server. FIG. 3B is a block schematic drawing of the streaming server of FIG. 3A showing the NAL header parser receiving an input from a local MP4 file reader. FIG. 3C shows the NAL header parser of FIG. 3A receiving an input from the network via a de-packetizer.
  • FIG. 4 shows a flowchart of operations at a sender side for abstraction-layer header parsing and network monitoring in accordance with the principles of the present invention, where the sender may be a transmitter, server or streaming server of FIG. 2A or FIG. 3. FIG. 4 further shows a data receiver and associated network monitoring operations where the receiver may be the client of FIG. 2B or the streaming receiver of FIG. 3.
  • FIG. 5 shows an exemplary data contents representation format of a scalable video coder (SVC) Network Abstraction Layer (NAL) extension header for parsing in accordance with the principles of the present invention.
  • FIG. 6 shows an exemplary format of a real-time protocol (RTP) header in which priority data may be transmitted and from which network statistics may be calculated in accordance with aspects of the present invention.
  • FIG. 7 shows an exemplary format of an MPEG transport stream (TS) header, for example, MPEG-2, including a continuity counter (CC) field from which network monitoring statistics may be derived according to aspects of the present invention.
  • FIG. 8 shows an exemplary format of a message including a transmission request and end-to-end packet loss rate from which network monitoring statistics may be derived according to aspects of the present invention.
  • FIG. 9 shows a first exemplary format of an ARQ request (NACK) packet from which network monitoring statistics may be derived according to aspects of the present invention.
  • FIG. 10 shows a second exemplary format of an RMP ARQ Request (NACK) packet in which network monitoring statistics may be transmitted and derived according to aspects of the present invention.
  • The present invention is directed to a method and apparatus at a transmitter or sender for parsing an abstraction-layer header as an input to the real-time (for example, real-time protocol or RTP) packetization for a module for an improved reliable media protocol module per FIG's 2A and 2B and to a network monitor and retransmission decision maker of the transmitter/server 200 (FIG. 2A) which may utilize the parser priority output to selectively retransmit aata based on monitored network conditions, for example, packet loss rate. According to one embodiment, a network abstraction-layer, for example, an H.264/AVC Network Abstraction Layer (NAL) of a real-time video encoder such as an MPEG-4 scalable video encoder (SVC) comprises a header that provides fields that may be parsed to determine digital data priority. For example, the NAL is network-friendly and may represent either video telephony, for example, video conversational applications and non-conversational applications such as storage of a down-loaded movie in memory, a broadcast or multicast application or streaming application or other non-conversational application. The NAL, for example, may be defined to represent a plurality of abstraction-layer units in the form of packets having one or more bytes. The first byte of each NAL unit may be a header byte indicating the type of data of the unit while remaining bytes contain payload data of a type indicated by the NAL header.
  • According to one embodiment, an abstraction-layer header parser comprises parsing a scalable video encoder abstraction-layer header to obtain data from one of a plurality of fields. According to aspects of this embodiment, the abstraction-layer header parser may operate, for example, on output digital video data of an MPEG 4 file reader or accept digital data from a network as received at a de-packetizer. For example, the abstraction-layer header parser may parse a DID field which represents an inter-layer coding dependency level of layer representation. A QID field represents a quality level of medium grain scalability (MGS) layer representation. A TID field represents a temporal level of layer representation. One result of parsing an abstraction-layer header, comprising such fields, is to identify the layer that the following payload data is associated with. One result of parsing an abstraction-layer header, comprising such fields, is to identify the layer that the following payload data is associated with. Responsive to the identification of the payload data type, one may assign a different priority for each identified layer. For example, a base layer may receive a high priority for retransmission from buffer or cache memory since base layer is absolutely necessary for a complete decoding at a receiver. Responsive to the identification of the payload data type, the parser may assign a different priority for each identified layer for the following data. For example, a base layer may receive a high priority for retransmission from buffer or cache memory since base layer data is absolutely necessary for a complete decoding at a receiver. An enhancement layer may be assigned a medium priority since enhancement layer data is necessary for decoding of a higher layer. On the other hand, a high enhancement layer of payload data may be assigned a low priority. Once assigned a priority, for example, low, medium and high, the priority information may be represented in a “payload type” (PT) or similar field of a real-time protocol (RTP) header, if retransmission is called for at the transport layer, or in a type of service (TOS) field of an IP header. A type of service field may be also known in the art, by way of example, as a differential services (DS) field. The first two bits are known as explicit congestion notification (ECN) bits, and the next six bits of a DS field byte are known as differential services code point (DSCP) bits. Type of service will be generally used herein to refer to these and other formats for providing type of service data. A real-time packet retransmission decision made by a reliable media protocol module may be thus layer-aware when modified to incorporate an abstraction-layer header parser and method according to one embodiment.
  • In a further embodiment, a network monitor is provided for monitoring data network quality via a data network interface and, for example, collecting current network data statistics for input to a retransmit decision maker, for example, packet loss rate, available bandwidth, and round-trip delay. The retransmit decision maker, in turn, may provide an input to the reliable media protocol (RMP) module so that a decision on retransmission may be based on current network conditions according to the data network statistical data collected at the network monitor and selectively decide to retransmit a packet based on its priority and the monitored network conditions.
  • Accordingly, a digital transmission method comprises parsing an abstraction-layer header of a digital data packet to obtain layer representation data, and assigning a priority to the digital data packet for the representation layer responsive to the parsing. Obtaining layer representation data may comprise one or all of determining inter-layer coding dependency level, determining a quality level of grain scalability and determining temporal level of the layer representation. Moreover, the method may further comprise one of representing the priority level in a payload type field of a real-time transport packet header or in a type of service field of an internet protocol packet header. As described above, an input to the abstraction-layer header parser may be received from a de-packetizer for receiving network data or received from a local server memory such as one associated with an MPEG file reader.
  • Moreover, in a further embodiment, a digital data transmitter may comprise an abstraction-layer header parser to obtain layer representation data from a digital data packet and assign a priority to the layer representation data, a digital data monitor for collecting network transport statistics, and a retransmission decision maker for deciding whether to retransmit a digital data packet based on the assigned digital data packet priority and the collected network transport statistics. As explained above, such an abstraction-layer header parser in a further embodiment may be a network abstraction-layer header parser for digital video data packet applications.
  • More specifically, referring to FIGS. 2-10, an abstraction-layer header parser, a data monitor and a retransmit decision maker of a server and a network monitor of a receiver provide for a highly reliable operation of RMP module 235 in making a decision whether or not to retransmit a packet that has been reported lost over a transmit control channel 255 as will be further described herein. Video transmission or distribution in wireless networks typically use real-time transport protocol (RTP), motion picture expert group 2 transport stream (MPEG2TS) over UDP. Real-time video could be distributed from a single source to a single destination (unicast mode) or from a single source to multiple destinations (multicast mode). Since channel conditions vary in wireless networks, packet transmissions, when the channel conditions are not good, result in dropped packets if the link layer error recovery is not successful. In these situations, there is a gap in the packet sequence resulting in poor viewing quality for the end user. The present invention provides an abstraction-layer header parsing functionality for an efficient application-layer based retransmission scheme, called reliable media protocol (RMP) herein, to recover packet losses to aid in reliable real-time streaming applications. The present invention also provides network monitoring capabilities at a transmitter and at a receiver side to improve packet retransmission decision making at server/transmitter 200 of FIG. 2A. Consequently, a network monitor 271 is provided at a receiver/client 201 of FIG. 2B.
  • Referring to FIGS. 2A and 2B, in the reliable media protocol (RMP) method of the present invention, RTP packetization 220 and a reliable media protocol (RMP) module 230 are assisted by the inclusion of NAL header parser 210 according to the principles of the present invention. Moreover, a network monitor 270 interfacing to network interface 250 collects current network statistics and, via retransmit decision maker 275, improves the reliability of RMP module 230. NAL header parser 210, network monitor 270 and retransmit decision maker 275 are highlighted in FIG. 2A to show that FIG. 2A is different from FIG. 1 as will be further explained below.
  • Initially, RMP module 230 transmits the regular unicast and multicast data or packets using UDP 240 via network interface 250 to transmit packets using initial transmit channel 260 to network 110. Data is initially stored in local cache 235 with a priority assigned by NAL header parser 210 via RTP packetization 220. Apart from this, an additional reliable TCP-based control channel 245 is established between the source (transmitter, sender) 200 of FIG. 2A and the destination (receiver, sink, client) 201 of FIG. 2B. TCP/IP 245 requests the retransmission of and receives lost packets through network interface 250 via retransmit ACK/NACK control channel 255 to network 110. For this mechanism to work properly, the transmitter (sender, server) 200 maintains a cache 235 of the most recent packets that were sent to its receivers/clients. One or more receivers/clients 201 receive the data packets from the transmitter/server 200 and may detect sequence gaps in the received data packets using the sequence number field present in the RTP (FIG. 6) or MPEG transport stream (TS) header (FIG. 7). If the receiver 201 detects a sequence gap, the receiver 201 sends a request on the TCP-based control channel 255 for selective retransmission of the missing data packets. When the transmitter/server 200 receives a retransmission request from one or more of its receivers/clients 201, it looks in its local cache 235 of most recent packets. If the requested packet(s) is/are found in the local cache 235, the sender/server 200 retransmits in unicast a copy of the packet to the receiver 201 on the TCP-based control channel 255 via network 110. If the requested packet was not found in its local cache/buffer 235, the sender 200 continues servicing the rest of the retransmission requests. The receiver/client 201 maintains a delivery queue (buffer/cache) 236 to hold all of the received data packets from both data and control channels. The receiver/client 201 also reorders the retransmitted packet into the correct sequence (position) within this queue and delivers the packets to the application in the proper order at the correct time, for example, a video player application 221 for display 206.
  • The receiver/client 201. (FIG. 2B) maintains a configurable time window to wait for any retransmissions rather than waiting forever so that the packet delay and delay jitter can be kept within the application bounds. Moreover, receiver/client 201 is provided with a network monitor 271 according to one embodiment for collecting network statistics from the perspective of the receiver/client 201 for transmission via control channel 255 to transmitter/server 200. Network monitor 271 is shown highlighted in FIG. 2B to show the cooperation between network monitor 271 and network interface 251 for collecting and providing network statistics according to the present invention to transmitter/server 200 for improved retransmission decision making as will be further described herein.
  • The receiver/client 201 of FIG. 2B passes the rest of the received packets from the delivery queue to the application, for example, video player 221 and display 206, if some of the retransmission replies for the lost packets are not received in time. If some of the retransmitted packets are received beyond the acceptable recovery time window they are discarded by the receiver. It should be noted that a video application can tolerate some data packet loss using error concealment technology in video decoding.
  • Referring again, to FIG. 2A, the reliable media protocol (RMP) scheme in the present invention operates via RMP module 230, 231 between the real-time application/RTP/MPEG TS and UDP/TCP/IP through the assistance of parser 210 for prioritization and improved retransmit decision making with the assistance of network monitors 270 and 271. At server/transmitter 200, an abstraction-layer header parser, for example, Network Abstraction Layer (NAL) header parser 210 operates on locally provided or network provided digital video data 205. NAL header parser 210 outputs a priority and the data for real-time protocol (RTP) packetization 220. Moreover, a network monitor 270 recovers current network 110 statistics and outputs control data to retransmit decision maker 275 to aid RMP module 230. For example, in furtherance to the example of an enhancement layer assigned a medium priority versus a base layer assigned a high priority, RMP module 230 will retransmit the high priority base layer data and not transmit the medium priority enhancement layer data in the face of an available bandwidth detected by network monitor 270 below a given threshold value. For example, rather than transmit all packets held in cache/buffer memory 235, a retransmission decision maker 275 may select a portion of the packets held in memory 235 for retransmission based on network monitor collected statistics, such as packet loss rate or other network conditions, and a priority assigned by NAL header parser 210. Thus the combination of assigning a priority to data at parser 210 in combination with retransmit decision making according to retransmit decision maker 275 provides for a highly reliable media protocol (RMP) module 230 as will be further described in connection with a discussion of FIG. 4.
  • Referring again the FIG. 2A, a typical network interface 250 is shown between network 110 and RMP module 230 at server/transmitter 200. Examples of network interface modules are Ethernet cards, IEEE 802.11/WiFi cards that connect to the computer network 110.
  • FIG. 2B shows the schematic of an exemplary implementation of a client device 201. The client may includes a video player/streaming application module 221, a display 206, a buffer (cache memory) 236, a reliable media protocol (RMP) module 231, a UDP/IP module 241, a TCP/IP module 246 and a network interface 251. The network interface 251 may be, for example, an Ethernet interface or an IEEE 802.11 interface or other known network interface. The network interface 251 receives all incoming messages. The messages arrive on different sockets/addresses. Network monitor 271 collects current network statistics from the perspective of receiver/client 201 from network interface 251 and outputs a suitable control message on channel 255 reporting on collected statistics. The network interface 251 can thus determine where to forward received messages from network 110 and output statistics data from network monitor 271 and messages from TCP/IP module 246. New incoming data packets are forwarded to the UDP/IP interface by the network interface module 251. Requests for retransmission of data packets and the retransmitted data packets are forwarded to the TCP/IP module 246 by the RMP module 231. The RMP module 231 determines if any of the received data packets have been corrupted and makes use of both UDP/IP and TCP/IP to orchestrate the packet recovery. The RMP module 231 generates a retransmission request for any corrupted data packets. The RMP module 231 then forwards the retransmission request to the TCP/IP module 246 for transmission over the network 110. At the network interface 251, any network statistics data collected by network monitor 271 are incorporated into the retransmission request for transmission over network 110. The RMP module 231 also stores the received packets in the local buffer 236 for reordering. Once the retransmitted packets are received from the TCP control channel via the TCP/IP module 246, the RMP module 231 arranges the packets in the correct order. The RMP 231 maintains a queue that is sorted on the sequence number and will reorder and insert packets into this buffer area/queue. When the recovery window expires, the RMP module 231 delivers the packets, for example, to the player/streaming application 221 for display 206. The RMP module 231 provides a socket-like application protocol interface (API) 216 for data passing and integration with the application. Note that some packets may not be recovered by the timeout of recovery window.
  • Data packets arriving after the expiration of the recovery window are discarded per FIG. 4. Depending on the application, for example, for video, the streaming/player application 221 depacketizes and/or decodes the data and passes the data to the display/speaker 206. The incoming packets are stored in the RMP “Buffer area” and will be handed over, for example, to the application for rendering (display) 206 whenever an application requests a packet. The box labeled “Config” 226 is a “Configuration Interface” to the RMP module 231. RMP module can be configured at the time of initialization to set parameters such as cache size, maximum time to wait for packet recovery etc.
  • At a receiver/client 201 according to FIG. 2B, a network monitor 271 may collect current network statistics at network monitor 271 from the perspective of receiver/client 201 via interface 251 and output the network experience of client/receiver 201 via control channel 255 to a server with which it is connected via digital data network 110. Upon receipt at transmitter/server 200 via network 110, such collected network statistics are output via interface 250 to network monitor 270 to supplement statistics gathered by network monitor 270 from the perspective of the transmitter/server of network 110 as discussed above. Digital data network 110 may be any digital data network including but not limited to satellite networks, land-based wireless networks, fiber optic networks, coaxial cable networks, twisted pair networks, local area networks, wide area networks and other known digital data networks. A typical network interface 251 is shown between network 110 and RMP module 231 at client/receiver 201. Examples of network interface modules include Ethernet cards, IEEE 802.11/WiFi cards and the like that connect to the computer network 110.
  • Before discussing FIG. 3, it is of import to note that similar reference numerals denote similar elements in the drawings. Moreover, the first number of a reference number such the first number 1 of reference number 110 for network 110 indicates the figure number where the element first appears. Consequently, for example, RMP module 230 first appears in FIG. 2, is similar to reliable media protocol (RMP) module 130 of FIG. 1, but is a different module from reliable media protocol (RMP) module 130 of FIG. 1, because of the introduction of NAL Header Parser 210 and Network Monitor 270 and Retransmit Decision Maker 275, all of which are not found in FIG. 1. Also, network monitor 271 of client/receiver 201 of FIG. 2B, in accordance with the principles of the present invention, improves the operation of RMP module 230 and Retransmit Decision Maker 275 of FIG. 2A. Some of the advantages of parser 210, network monitors 270 and 271 and retransmit decision maker 275 have been described above but will be further described in connection with the discussion of FIGS. 3 and 4 below.
  • FIG. 3 provides a direct representation of NAL abstraction-layer header parser 210, network monitor 270 and retransmit decision maker 275 of a streaming server/transmitter with reference to transmission to one or more streaming receivers connected via network 110. Referring to FIG. 3A, there is shown a scalable video coder (SVC) encoder 300 which may be located at the streaming server or remotely from it. A scalable video coder (SVC) provides temporal or frame rate scalability, spatial or picture size scalability (video is, for example, coded at multiple resolutions and aspect ratios) and signal-to-noise ratio (SNR) or quality/fidelity scalability as will be described further herein. NAL header parser 210 may be an H.264 compliant AVC Network Abstraction Layer (NAL) header parser or other abstraction-layer header parser with similar functionality as will be further described in connection with FIG. 4. For example, with reference to FIG. 3B, NAL header parser 210 may receive an input from local memory store, for example, an MP-4 file reader 302. An exemplary streaming server embodiment may be a streaming server for providing IP television channel or movie services. In alternative embodiment FIG. 3C, there is shown a de-packetizer 304 for receiving, for example, streaming video from the network 110 and outputting the received packets to NAL header parser 210. An exemplary video application of the streaming server of FIG. 3C may be video telephony where the depicted streaming server is one server in a network path from one video communications terminal to another.
  • In each of FIGS. 3A, 3B and 3C, the NAL header parser 210 may provide a packet/frame priority via packetizer 310 to local cache 235. For initial transmission, parser 210 outputs parser data and priority to packetizer 310. Per path 312, a copy is placed in local cache 235 and per path 314, the packetizer sends packet data to depacketizer 320 of streaming receiver. Network monitor 270 provides network transport condition data to retransmission decision maker 275 for selectively deciding on whether or not to retransmit a packet/frame stored in local cache 235 for retransmission over path 316 via network 110 to de-packetizer 320. Path 316 is used for retransmission of selected packets according to transport conditions and parser assigned priority.
  • Now, with reference to FIG. 4, the functional operation of an abstraction-layer header parser, network monitor and retransmission decision maker according to the present invention will be further described with reference to the depicted flowchart showing both sender or transmitter/server side operation and receiver/client/terminal side operation. At block 400, the server/transmitter of FIG. 3 obtains data, for example, from a local file, per FIG. 3B, file reader 302, or receives data from a network interface, for example, from network 110 and de-packetizer 304 of FIG. 3C. The received data is provided to block 410 which represents the abstraction-layer header parser 210 of FIGS. 2A and 3.
  • Referring briefly to FIG. 5, there is shown a typical abstraction-layer header, for example, an SVC NAL extension header, providing fields to be parsed. For example, the abstraction-layer header parser 410 may parse a DID field shown appearing at positions 1-3 of the second byte (BYTE 1) which represents an inter-layer coding dependency of layer representation or level of spatial/resolution scalability. A QID field at, for example, positions 4-7 of the second byte (BYTE 1), may follow and represents a quality level of medium grain scalability (MGS) layer representation. A TID field, for example, at positions 0-2 of the third byte (BYTE 2), represents a temporal level of layer representation. One result of parsing an abstraction-layer header comprising such fields is to identify the layer that the following payload data is associated with. Responsive to the identification of the payload data type, a parser at parser block 410 of FIG. 4 may assign a different priority for each identified layer for following data: for example, a low, medium and high priority. More than three levels of priority may be employed in alternative embodiments. For example, a base layer may receive a high priority for retransmission from buffer or cache memory since base layer is absolutely necessary for a complete decoding at a receiver. An enhancement layer may be assigned a medium priority since enhancement layer data is necessary for decoding of a higher layer. An SVC-encoded stream of digital data may comprise a base layer and one enhancement layer. On the other hand, a second or more enhancement layers may be provided for even greater picture quality enjoyment and, so, a higher enhancement layer may be assigned a low priority in cache 235 for associated payload data.
  • To provide a simplified example, if SVC-encoded video data has a base layer of a resolution of 416 by 240 and a bit rate of 600 kbps and one enhancement layer of a higher resolution of 832 by 480 and a consequent bit rate of 1.2 megabits per second for video streaming, then, the parser 410 can identify the base layer NAL units based on its DID field and assign the base layer a higher priority. On the other hand, the enhancement layer may be assigned a lower priority (to provide the higher resolution). The base layer is assigned the higher priority than the enhancement layer in this example. The output priority level may be indicated in a payload type (PT) field of an RTP header shown in FIG. 6 at positions 9-15. Once assigned a priority, for example, low, medium and high, the priority information may also be represented in a similar field of a real-time protocol (RTP) header, if retransmission is called for at the transport layer, or in a type of service (TOS) field of an IP header. Initially, a copy is buffered at block 420 in local cache/buffer memory at 430 as the packet is transmitted via “send the packet” 450 toward a receiver via network 110. The packet may be lost in the network or received. The packet in local cache 430 awaits a determination as to network conditions and whether the packet is received or not.
  • If the packet is received and network conditions appear to be good, the packet is received 460 and the receiver determines at 465 whether an expected packet is lost (Yes) or not (No). If lost (Yes), then at 485, a retransmit request is sent, and a recovery timer of a receiver is set via the control channel 255 of FIG. 2B back to the sender/transmitter/server 200. If no, then at 490, the received packet is placed in proper order in a receiving buffer, for example, for a display function 206 at the receiver/client 201.
  • If a retransmit request is sent via 485, a network monitor function 405 is actuated and the received retransmit request is then processed. As will be described further herein, an end-to-end packet loss rate at a given time may be determined at a network monitor 271 as a current network 110 condition from the receiver side. The current network condition, for example, an end-to-end packet loss rate, is provided with the retransmit request as an output of 405 to retransmission decision maker 415.
  • An exemplary application of a network monitor 405 may be where the sender/server is on a wired network 110, for example, a set-top box (cable or satellite) or home gateway and the receiver is a mobile device or personal computer that is associated with a wireless access point AP. An intermediate node/wireless access point (AP/router) may report the network and wireless channel conditions to the sender. A real-time packet retransmission decision made by a reliable media protocol (RMP) module 230 according to the principles of the present invention may be thus layer-aware when modified to incorporate an abstraction-layer header parser and method according to one embodiment.
  • Retransmission decision maker 415 questions whether, for example, the current end-to-end transmit packet loss rate is high, meaning whether it is above a threshold level set in memory of the RMP module 230. If the answer is YES, then, at 445, lower priority packets are dropped, and only higher priority packets are recovered from cache/buffer 430 and retransmitted. Other measures of transport conditions besides packet loss rate may be available bandwidth (for example, the lowest available bandwidth in an end-to-end path) and round-trip delay (a longer round-trip delay may require the time-out of a packet held in cache/buffer 235 for retransmission). Each of these, including available bandwidth, may be compared with an associated threshold level set in memory for deciding on packet retransmission. One or more may be employed in making the retransmission decision as well as packet priority set by parsing 410. If the answer is returned NO, at 435, all requested packets are retransmitted from cache/buffer 430 via “send the packet” 450 and network 110.
  • Upon receipt, the retransmitted packet is received at 460 and recognized as a retransmitted packet at 470. Given a real-time viewing experience, the time of receipt is examined at 475. The question is asked: Retransmit late? If the retransmitted packet is received too late, that is, the program viewing experience has already moved on to a next frame, then, the retransmit packet is discarded at 480. On the other hand, if the retransmit packet is not late, (i.e., the answer is NO), the retransmit packet is placed in order in a receiving buffer for display at 490.
  • The RMP method of the present invention may be implemented in a flexible software library, hardware, firmware, any computer or processor, an application specific integrated circuit (ASIC), a reduced instruction set computer (RISC), a field programmable gate array (FPGA) or an combination thereof. The RMP method of the present invention uses socket-like user-space APIs and underlying transport means for easy integration with streaming server and player applications. The RMP method of the present invention is transparent to the streaming applications that it supports. The UDP data channel and the TCP control channel are internally maintained. The RMP method of the present invention is extensible to support other error recovery schemes such as FEC and hybrid ARQ.
  • The network monitor function 405 of the present invention will now be described further with reference to FIGS. 6, 7 and 8. One possible approach is shown in FIG. 6 where the network monitor 271, for example, may detect a sequence gap from a sequence number, positions 6-1 of first line. Another approach is to utilize a continuity counter (CC) field of an MPEG-2 transport stream header of one byte as seen in FIG. 7.
  • The exemplary format of the message for sending statistics collected by a network monitor 271 of a receiver/client 201 of FIG. 2B to server/transmitter 200 of FIG. 2A is shown in FIG. 8. The message format may be similar to an RTP Control Protocol (RTCP) receiver report (RR) message. In particular, one may provide a “fraction lost” field, for example, at positions 0-7 of line 4. Other relevant data may be provided such as a cumulative number of packets lost which may be compared with a previously received cumulative number of packets lost received on the same channel. The difference provides a number of packets lost within an interval defined by the time between successful receipt of successive messages.
  • FIG. 9 provides a format for a sender/server/transmitter obtaining network packet loss through the retransmission requests received from the receiver/client 201. A network monitor function 405 of FIG. 4 calculates a number of lost packets from the fields “Base sequence # of starting packet” and “offset for ending packet.” Similarly, the RMP ARQ request (NACK) packet of FIG. 10 provides a base sequence number which can be stored and compared with subsequently received base sequence numbers. The depicted base sequence number and the bitmap indicate the sequence of the packets that the receiver requests to be retransmitted. Yet another approach to determining network transport conditions is to monitor the lower layer, for example, network/MAC/PHY level transmission statistics to estimate the channel conditions and available bandwidth.
  • In the RMP scheme of the present invention described above, no alterations are made to the packets sent on the data channel 255. Thus, backward compatibility is maintained. Also the RMP scheme of the present invention makes efficient use of the bandwidth since only the lost media packets are requested and retransmitted on the control channel with low overhead. The lost packet requests serve as NACKs (Negative Acknowledgements) and also provide feedback to the sender. It can provide high reliability under widely different channel conditions because a lost packet can be retransmitted multiple times within the recovery time window. Also the RMP scheme of the present invention enforces the application's latency constraint by having a maximum wait time (i.e., a recovery window) for retransmissions and thus operates on the best effort delivery model within the given time constraint.
  • Note that the above embodiment is explained using video transmission. The present invention can also be applied to transmission of audio, for example, telephony, and other real-time multimedia streaming applications.
  • Though the above scheme of the present invention has been described with respect to wireless networks, the scheme could be used in any kind of network that involves packet losses.
  • It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware—such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform, such as an additional data storage device and a printing device.
  • It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.

Claims (23)

1. A method comprising:
monitoring a digital data network to collect network transport statistics; and
deciding whether to retransmit a digital data packet to a receiver based on said network transport statistics.
2. The method according to claim 1 wherein
collecting network statistics comprises collecting statistics from a receiver to generate a lost packet rate at the transmitter.
3. The method according to claim 2 wherein
said packet retransmit decision is based on comparing said generated lost packet rate with a predetermined threshold.
4. The method according to claim 1 wherein
collecting network statistics comprises monitoring network level transmission statistics and estimating available bandwidth.
5. The method according to claim 3 wherein
said packet retransmit decision is based on comparing said estimated available bandwidth with a predetermined threshold.
6. The method according to claim 1 wherein
said monitoring comprises
monitoring receiver missing packet data and recording data of one of packet loss rate and available bandwidth from a receiver and
assigning a missing packet threshold responsive to said monitoring.
7. The method according to claim 1 wherein
said monitoring comprises calculating a sequence gap via a continuity counter field of a transport stream header.
8. The method according to claim 1 wherein
said monitoring comprises calculating packet loss rate information from a fraction lost field of a receiver report packet.
9. The method according to claim 1 wherein
said monitoring comprises calculating a packet loss rate from a base sequence number of a starting packet and an offset for an ending packet.
10. An apparatus comprising:
a digital data network monitor for collecting network transport statistics; and
a retransmission decision maker for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and said collected network transport statistics.
11. The apparatus according to claim 10 further comprising
an abstraction-layer header parser coupled to a real-time transport protocol packetizer for assigning a priority level to a packet for retransmission.
12. The apparatus according to claim 10,
said digital data monitor and said retransmission decision maker being responsive to a network interface and for providing input to a reliable media protocol module.
13. The apparatus according to claim 10 further comprising
a buffer memory for temporary storage of digital data for transmission.
14. The apparatus according to claim 10 wherein
said network monitor monitors receiver missing packet data and records data of one of packet loss rate and available bandwidth from a receiver and assigns a missing packet threshold responsive to said monitoring.
15. The apparatus according to claim 10 wherein
said packet retransmit decision is based on comparing said estimated available bandwidth with a predetermined threshold.
16. The apparatus according to claim 10 wherein
said network monitor calculates a sequence gap via a continuity counter field of a transport stream header.
17. The apparatus according to claim 14 wherein
said network monitor calculates packet loss rate information from a fraction lost field of a receiver report packet.
18. The apparatus according to claim 14 wherein
said network monitor calculates a packet loss rate from a base sequence number of a starting packet and an offset for an ending packet.
19. The apparatus according to claim 11 further comprising
a buffer memory for temporary storage of digital data for retransmission according to said assigned priority level.
20. Apparatus comprising:
means for collecting network transport statistics; and
means for deciding whether to retransmit a digital data packet based on an assigned digital data packet priority and said collected network transport statistics.
21. The apparatus according to claim 20 further comprising
means for packetizing data into packets; and
means coupled to said data packetizing means for assigning a priority level to a packet for retransmission.
22. An apparatus comprising:
a network monitor for collecting network statistics from the perspective of a receiver apparatus; and
a network interface for outputting a control channel message including said collected network statistics.
23. An apparatus comprising:
means for collecting network statistics from the perspective of a receiver apparatus; and
means for outputting a control channel message including said collected network statistics.
US13/575,646 2010-01-28 2010-01-28 Method and apparatus for retransmission decision making Abandoned US20120300663A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2010/000228 WO2011093836A1 (en) 2010-01-28 2010-01-28 A method and apparatus for retransmission decision making

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2010/000228 A-371-Of-International WO2011093836A1 (en) 2009-10-07 2010-01-28 A method and apparatus for retransmission decision making

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/670,688 Division US9306708B2 (en) 2009-10-07 2015-03-27 Method and apparatus for retransmission decision making

Publications (1)

Publication Number Publication Date
US20120300663A1 true US20120300663A1 (en) 2012-11-29

Family

ID=42938588

Family Applications (2)

Application Number Title Priority Date Filing Date
US13/575,646 Abandoned US20120300663A1 (en) 2010-01-28 2010-01-28 Method and apparatus for retransmission decision making
US14/670,688 Expired - Fee Related US9306708B2 (en) 2009-10-07 2015-03-27 Method and apparatus for retransmission decision making

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14/670,688 Expired - Fee Related US9306708B2 (en) 2009-10-07 2015-03-27 Method and apparatus for retransmission decision making

Country Status (6)

Country Link
US (2) US20120300663A1 (en)
EP (1) EP2529502A1 (en)
JP (1) JP6067378B2 (en)
KR (1) KR101734835B1 (en)
CN (1) CN103109485A (en)
WO (1) WO2011093836A1 (en)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140294093A1 (en) * 2013-03-29 2014-10-02 Qualcomm Incorporated Rtp payload format designs
US20150195326A1 (en) * 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
US20160092317A1 (en) * 2014-09-29 2016-03-31 International Business Machines Corporation Stream-processing data
US20160255579A1 (en) * 2013-10-21 2016-09-01 Kyocera Corporation Base station, processor and terminal
US20160261380A1 (en) * 2015-03-02 2016-09-08 Lg Electronics Inc. Scalable service in a wireless communication system
US20160295379A1 (en) * 2015-01-19 2016-10-06 Vuclip (Singapore) Pte. Ltd. Offline content distribution networks
US20160352468A1 (en) * 2015-05-29 2016-12-01 Goodrich Corporation Multi-system data transfer protocol
US20170163561A1 (en) * 2011-01-19 2017-06-08 Samsung Electronics Co., Ltd. Method and apparatus for transmitting a multimedia data packet using cross-layer optimization
US20170288816A1 (en) * 2016-03-30 2017-10-05 Le Holdings (Beijing) Co., Ltd. Method and system for compensating hls slice loss
US10033489B1 (en) * 2014-12-22 2018-07-24 Amazon Technologies, Inc. Managing communications based on network conditions
US20180255325A1 (en) * 2017-03-01 2018-09-06 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions
US20180278372A1 (en) * 2016-05-25 2018-09-27 Tencent Technology (Shenzhen) Company Limited Voice data transmission method and device
WO2018212613A1 (en) * 2017-05-17 2018-11-22 Samsung Electronics Co., Ltd. Tcp proxy device-assisted communication method and apparatus in wireless communication
US20190288796A1 (en) * 2016-07-25 2019-09-19 Koninklijke Philips N.V. Robust data transmittal
US10531160B2 (en) 2015-08-19 2020-01-07 Yamaha Corporation Content transmission apparatus, content delivery system, and content transmission method
US10691528B1 (en) * 2019-07-23 2020-06-23 Core Scientific, Inc. Automatic repair of computing devices in a data center
US11330341B1 (en) 2016-07-05 2022-05-10 BoxCast, LLC System, method, and protocol for transmission of video and audio data
US11949512B2 (en) * 2016-02-26 2024-04-02 Livestreaming Sweden Ab Retransmission of data in packet networks
EP4135234A4 (en) * 2020-04-06 2024-05-22 Samsung Electronics Co., Ltd. Electronic device for retransmitting packets on basis of state of network and operation method thereof
US12126873B1 (en) 2022-10-24 2024-10-22 Boxcast Inc. Method and protocol for transmission of video and audio data

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9391878B2 (en) * 2012-01-25 2016-07-12 Cisco Technology, Inc. Reliable packet delivery with overlay network (RPDON)
US9577791B2 (en) 2012-12-05 2017-02-21 Intel Corporation Notification by network element of packet drops
US9680610B2 (en) * 2012-12-13 2017-06-13 Thomson Licensing Method and apparatus for error control in 3D video transmissoin
US8989017B2 (en) * 2012-12-14 2015-03-24 Intel Corporation Network congestion management by packet circulation
US9774869B2 (en) * 2013-03-25 2017-09-26 Blackberry Limited Resilient signal encoding
CN105208442B (en) * 2014-06-27 2018-06-26 贝壳网际(北京)安全技术有限公司 A kind of video broadcasting method and device of video playing application program
CN106788911A (en) * 2015-11-25 2017-05-31 华为技术有限公司 A kind of method and apparatus of message retransmission
US10841203B2 (en) 2015-12-11 2020-11-17 Qualcomm Incorporated Coordination of multiple routes for a single IP connection
US10425667B2 (en) * 2016-10-03 2019-09-24 Cisco Technology, Inc. Network layer transport of video characteristics for use by network function in a service function chain
EP3676979A1 (en) * 2017-08-31 2020-07-08 Nokia Technologies Oy Method for operating a network entity, network entity, method to operate a user equipment, and user equipment
JP7023384B2 (en) * 2018-05-04 2022-02-21 シトリックス・システムズ・インコーポレイテッド Computer systems and related methods that provide hierarchical display remoting optimized with user and system hints
US11824785B2 (en) * 2018-05-04 2023-11-21 Citrix Systems, Inc. Systems and methods for remote computing session display based upon user input event prioritization
US11943153B2 (en) * 2021-06-28 2024-03-26 Dish Wireless L.L.C. Using buffered audio to overcome lapses in telephony signal

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070206497A1 (en) * 2003-07-29 2007-09-06 Robert Plamondon Systems and methods for additional retransmissions of dropped packets
US20110134748A1 (en) * 2009-12-08 2011-06-09 At&T Intellectual Property I, L.P. Bulk Data Transport in a Network

Family Cites Families (67)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0391314A (en) 1989-09-04 1991-04-16 Fuji Electric Co Ltd Flip-flop circuit
JPH07221789A (en) 1994-01-27 1995-08-18 Hitachi Ltd Method and system for continuous data transmission
US5822524A (en) 1995-07-21 1998-10-13 Infovalue Computing, Inc. System for just-in-time retrieval of multimedia files over computer networks by transmitting data packets at transmission rate determined by frame size
US5764307A (en) 1995-07-24 1998-06-09 Motorola, Inc. Method and apparatus for spatially adaptive filtering for video encoding
JPH09191314A (en) * 1996-01-10 1997-07-22 Mitsubishi Electric Corp Continuous data transmission method and its transmitter
JP3193947B2 (en) 1997-01-08 2001-07-30 株式会社ディジタル・ビジョン・ラボラトリーズ Data transmission system and data transmission method
US5918002A (en) 1997-03-14 1999-06-29 Microsoft Corporation Selective retransmission for efficient and reliable streaming of multimedia packets in a computer network
US6289054B1 (en) * 1998-05-15 2001-09-11 North Carolina University Method and systems for dynamic hybrid packet loss recovery for video transmission over lossy packet-based network
JP2000036837A (en) 1998-07-21 2000-02-02 Matsushita Electric Ind Co Ltd Arq image communication method
US6782277B1 (en) 1999-09-30 2004-08-24 Qualcomm Incorporated Wireless communication system with base station beam sweeping
US7389356B2 (en) 1999-12-15 2008-06-17 Microsoft Corporation Generalized differentiation methods and arrangements for adaptive multimedia communications
JP3637835B2 (en) 2000-03-22 2005-04-13 松下電器産業株式会社 Network transmission equipment
JP2002084338A (en) 2000-07-07 2002-03-22 Matsushita Electric Ind Co Ltd Data transmitter, data receiver and data communication system
JP2002141964A (en) * 2000-08-24 2002-05-17 Matsushita Electric Ind Co Ltd Transmission reception method and its system
JP2002084239A (en) 2000-09-06 2002-03-22 Nippon Telegr & Teleph Corp <Ntt> Media information distribution system and media information distribution method
US7307963B2 (en) 2001-08-03 2007-12-11 At&T Corp. Architecture and method for using IEEE 802.11-like wireless LAN system to emulate private land mobile radio system (PLMRS) radio service
US7218610B2 (en) * 2001-09-27 2007-05-15 Eg Technology, Inc. Communication system and techniques for transmission from source to destination
EP1449331B1 (en) 2001-11-30 2007-09-19 British Telecommunications Public Limited Company Data transmission
JP3757857B2 (en) 2001-12-12 2006-03-22 ソニー株式会社 Data communication system, data transmission apparatus, data reception apparatus and method, and computer program
US20030206549A1 (en) 2002-05-03 2003-11-06 Mody Sachin Satish Method and apparatus for multicast delivery of information
KR100876765B1 (en) 2002-05-10 2009-01-07 삼성전자주식회사 Apparatus for retransmitting data in mobile communication system and method thereof
CN1324851C (en) 2002-06-11 2007-07-04 汤姆森许可贸易公司 Multimedia server with simple adaptation to dynamic network loss conditions
JP2004038575A (en) 2002-07-03 2004-02-05 Sony Corp Data transmitting and receiving system, data transmitting and receiving method, information providing device, information providing method, data transmitting device, and data receiving method
US20060164987A1 (en) 2002-07-18 2006-07-27 Carles Ruiz Floriach Adaptive dropping of prioritized transmission packets
JP2004056393A (en) 2002-07-18 2004-02-19 Fujitsu Ltd Correction system for storage result of reproduced data
US7254765B2 (en) 2002-09-24 2007-08-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for error tolerant data transmission, wherein retransmission of erroneous data is performed up to the point where the remaining number of errors is acceptable
US20090119717A1 (en) 2002-12-11 2009-05-07 Koninklijke Philips Electronics N.V. Method and system for utilizing video content to obtain text keywords or phrases for providing content related to links to network-based resources
US20040240415A1 (en) 2003-06-02 2004-12-02 Richard Lane Base station-centric method for managing bandwidth and QoS in error-prone system
JP4328602B2 (en) 2003-11-20 2009-09-09 富士通株式会社 Packet error correction apparatus and method
US7643480B2 (en) * 2004-01-22 2010-01-05 Hain-Ching Liu Method and system for reliably and efficiently transporting data over a network
KR100639650B1 (en) 2004-06-15 2006-10-30 주식회사 케이티프리텔 Vod streaming service system and method thereof
JP2006013911A (en) 2004-06-25 2006-01-12 Nippon Telegr & Teleph Corp <Ntt> Stream data transfer method, apparatus and program, and recording medium
US7522528B2 (en) 2004-11-18 2009-04-21 Qvidium Technologies, Inc. Low-latency automatic repeat request packet recovery mechanism for media streams
US20090252219A1 (en) 2004-12-15 2009-10-08 Koninklijke Philips Electronics, N.V. Method and system for the transmission of digital video over a wireless network
JP2006203649A (en) 2005-01-21 2006-08-03 Matsushita Electric Ind Co Ltd Video transmission device and system
EP1699158A1 (en) 2005-03-02 2006-09-06 Evolium S.A.S. A method for selection of the appropriate HARQ retransmission scheme for data transmission, a base station and a program therefor
MX2007014744A (en) 2005-05-24 2008-02-14 Nokia Corp Method and apparatuses for hierarchical transmission/reception in digital broadcast.
WO2007046957A1 (en) 2005-10-12 2007-04-26 Thomson Licensing Method and apparatus for using high-level syntax in scalable video encoding and decoding
KR100724825B1 (en) * 2005-11-17 2007-06-04 삼성전자주식회사 A Methodology and System for Scalable Video Bitstream Encryption and Decryption to Scalable Conditional Access Control according to Multi-dimensionalScalability in Scalable Video Coding
CN101371312B (en) * 2005-12-08 2015-12-02 维德约股份有限公司 For the system and method for the error resilience in video communication system and Stochastic accessing
US8462627B2 (en) 2005-12-30 2013-06-11 Altec Lansing Australia Pty Ltd Media data transfer in a network environment
CN101018109B (en) 2006-02-09 2010-06-23 中兴通讯股份有限公司 A mobility management method of the automatic retransfer request
KR101162378B1 (en) 2006-03-08 2012-07-04 삼성전자주식회사 Method and apparatus for harq reordering using retransmission limit in a mobile communication system
US8036101B2 (en) 2006-05-08 2011-10-11 Samsung Electronics Co., Ltd Retransmission apparatus and method for high-speed data processing
KR20070109313A (en) 2006-05-10 2007-11-15 삼성전자주식회사 Apparatus and method of efficient ack transmission in harq assisted arq operation for high rate data transmission
CN101087184A (en) 2006-06-01 2007-12-12 创新音速有限公司 Method and related device for wireless communication system improving data transmission efficiency
WO2008024282A2 (en) 2006-08-21 2008-02-28 Interdigital Technology Corporation Method and apparatus for controlling arq and harq transmissions and retranmissions in a wireless communication system
KR100855347B1 (en) 2006-12-05 2008-09-04 에스케이 텔레콤주식회사 Message transmitting system based on udp control and method for the same
US8411572B2 (en) 2006-12-13 2013-04-02 Viasat, Inc. ACM and fixed coding and modulation of hierarchical layers
US8254392B2 (en) 2006-12-18 2012-08-28 Telefonaktiebolaget L M Ericsson (Publ) Link layer control protocol implementation
CA2674710C (en) * 2007-01-09 2016-02-23 Vidyo, Inc. Improved systems and methods for error resilience in video communication systems
US9344362B2 (en) 2007-01-12 2016-05-17 University-Industry Cooperation Group Of Kyung Hee University Packet format of network abstraction layer unit, and algorithm and apparatus for video encoding and decoding using the format, QOS control algorithm and apparatus for IPV6 label switching using the format
US20080198787A1 (en) 2007-02-15 2008-08-21 Agentek, Inc. Mobile Data Object Transmission Over Wireless Communication Networks Using UDP and Two Level Protocol
KR101345944B1 (en) 2007-03-02 2013-12-27 삼성전자주식회사 Apparatus and method for retransmission request of packet using arq and harq scheme in radio communication system
CN101682565B (en) * 2007-03-12 2015-08-19 思杰系统有限公司 For being carried out the system and method for dynamic bandwidth control by agency
JP5084362B2 (en) * 2007-06-18 2012-11-28 キヤノン株式会社 Data transmission apparatus and data transmission / reception system
KR101015888B1 (en) 2007-09-11 2011-02-23 한국전자통신연구원 Method and Apparatus for computing the distortion value of the video packet for priority assignment in scalable video coding
US7867406B2 (en) 2007-12-26 2011-01-11 Hitachi Global Storage Technologies Netherlands, B.V. Patterned magnetic media having an exchange bridge structure connecting islands
TW200931869A (en) 2007-12-31 2009-07-16 Interdigital Patent Holdings Method and apparatus for handling interactions between measurement gap, automated repeat request, discontinuous reception and discontinuous transmission in wireless communications
US8752102B2 (en) * 2008-01-03 2014-06-10 Microsoft Corporation Intelligent retransmission of data stream segments
CN101262321A (en) 2008-02-03 2008-09-10 杭州华三通信技术有限公司 Media data processing method, coding device and media platform
CN101262604A (en) 2008-04-23 2008-09-10 哈尔滨工程大学 A telescopic video coding method for optimized transmission of interested area
US20110090921A1 (en) 2008-07-01 2011-04-21 Shemimon Manalikudy Anthru Network abstraction layer (nal)-aware multiplexer
KR101374452B1 (en) 2008-10-30 2014-03-17 노키아 코포레이션 Method and apparatus for interleaving a data block
US8391356B1 (en) * 2009-02-18 2013-03-05 Sprint Communications Company L.P. Scalable video coding priority marking
EP2486686A1 (en) 2009-10-07 2012-08-15 Thomson Licensing An efficient application-layer automatic repeat request retransmission method for reliable real-time data streaming in networks
KR101644215B1 (en) 2010-01-28 2016-08-09 톰슨 라이센싱 A method and apparatus for parsing a network abstraction-layer for reliable data communication

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070206497A1 (en) * 2003-07-29 2007-09-06 Robert Plamondon Systems and methods for additional retransmissions of dropped packets
US20110134748A1 (en) * 2009-12-08 2011-06-09 At&T Intellectual Property I, L.P. Bulk Data Transport in a Network

Cited By (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170163561A1 (en) * 2011-01-19 2017-06-08 Samsung Electronics Co., Ltd. Method and apparatus for transmitting a multimedia data packet using cross-layer optimization
US10630603B2 (en) * 2011-01-19 2020-04-21 Samsung Electronics Co., Ltd. Method and apparatus for transmitting a multimedia data packet using cross-layer optimization
US11316799B2 (en) 2011-01-19 2022-04-26 Samsung Electronics Co., Ltd. Method and apparatus for transmitting a multimedia data packet using cross-layer optimization
US20140294064A1 (en) * 2013-03-29 2014-10-02 Qualcomm Incorporated Rtp payload format designs
US20140294093A1 (en) * 2013-03-29 2014-10-02 Qualcomm Incorporated Rtp payload format designs
US9723305B2 (en) 2013-03-29 2017-08-01 Qualcomm Incorporated RTP payload format designs
US9641834B2 (en) * 2013-03-29 2017-05-02 Qualcomm Incorporated RTP payload format designs
US9667959B2 (en) * 2013-03-29 2017-05-30 Qualcomm Incorporated RTP payload format designs
US20160255579A1 (en) * 2013-10-21 2016-09-01 Kyocera Corporation Base station, processor and terminal
US20150195326A1 (en) * 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
US10579453B2 (en) * 2014-09-29 2020-03-03 International Business Machines Corporation Stream-processing data
US10146502B2 (en) * 2014-09-29 2018-12-04 International Business Machines Corporation Stream-processing data
US20160092317A1 (en) * 2014-09-29 2016-03-31 International Business Machines Corporation Stream-processing data
US20190079725A1 (en) * 2014-09-29 2019-03-14 International Business Machines Corporation Stream-processing data
US10033489B1 (en) * 2014-12-22 2018-07-24 Amazon Technologies, Inc. Managing communications based on network conditions
US10367882B2 (en) 2015-01-19 2019-07-30 Pccw Vuclip (Singapore) Pte. Ltd. Offline content distribution networks
US20160295379A1 (en) * 2015-01-19 2016-10-06 Vuclip (Singapore) Pte. Ltd. Offline content distribution networks
US9730033B2 (en) * 2015-01-19 2017-08-08 Vuclip (Singapore) Pte. Ltd. Offline content distribution networks
US20160261380A1 (en) * 2015-03-02 2016-09-08 Lg Electronics Inc. Scalable service in a wireless communication system
US10135577B2 (en) * 2015-03-02 2018-11-20 Lg Electronics Inc. Scalable service in a wireless communication system
US10735142B2 (en) * 2015-05-29 2020-08-04 Goodrich Corporation Multi-system data transfer protocol
US20160352468A1 (en) * 2015-05-29 2016-12-01 Goodrich Corporation Multi-system data transfer protocol
US10531160B2 (en) 2015-08-19 2020-01-07 Yamaha Corporation Content transmission apparatus, content delivery system, and content transmission method
US11949512B2 (en) * 2016-02-26 2024-04-02 Livestreaming Sweden Ab Retransmission of data in packet networks
US20170288816A1 (en) * 2016-03-30 2017-10-05 Le Holdings (Beijing) Co., Ltd. Method and system for compensating hls slice loss
US10594449B2 (en) * 2016-05-25 2020-03-17 Tencent Technology (Shenzhen) Company Limited Voice data transmission method and device
US20180278372A1 (en) * 2016-05-25 2018-09-27 Tencent Technology (Shenzhen) Company Limited Voice data transmission method and device
US11483626B1 (en) 2016-07-05 2022-10-25 BoxCast, LLC Method and protocol for transmission of video and audio data
US11330341B1 (en) 2016-07-05 2022-05-10 BoxCast, LLC System, method, and protocol for transmission of video and audio data
US20190288796A1 (en) * 2016-07-25 2019-09-19 Koninklijke Philips N.V. Robust data transmittal
US20180255325A1 (en) * 2017-03-01 2018-09-06 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions
US10841621B2 (en) * 2017-03-01 2020-11-17 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions
WO2018212613A1 (en) * 2017-05-17 2018-11-22 Samsung Electronics Co., Ltd. Tcp proxy device-assisted communication method and apparatus in wireless communication
US10693800B2 (en) 2017-05-17 2020-06-23 Samsung Electronics Co., Ltd. TCP proxy device-assisted communication method and apparatus in wireless communication
US11249835B2 (en) 2019-07-23 2022-02-15 Core Scientific, Inc. Automatic repair of computing devices in a data center
US10691528B1 (en) * 2019-07-23 2020-06-23 Core Scientific, Inc. Automatic repair of computing devices in a data center
EP4135234A4 (en) * 2020-04-06 2024-05-22 Samsung Electronics Co., Ltd. Electronic device for retransmitting packets on basis of state of network and operation method thereof
US12126873B1 (en) 2022-10-24 2024-10-22 Boxcast Inc. Method and protocol for transmission of video and audio data

Also Published As

Publication number Publication date
EP2529502A1 (en) 2012-12-05
CN103109485A (en) 2013-05-15
WO2011093836A1 (en) 2011-08-04
JP6067378B2 (en) 2017-01-25
JP2013518511A (en) 2013-05-20
KR20120117907A (en) 2012-10-24
KR101734835B1 (en) 2017-05-19
US9306708B2 (en) 2016-04-05
US20150200750A1 (en) 2015-07-16

Similar Documents

Publication Publication Date Title
US9306708B2 (en) Method and apparatus for retransmission decision making
EP2529528B1 (en) A method and apparatus for parsing a network abstraction-layer for reliable data communication
KR100941562B1 (en) Medium streaming distribution system
KR101242663B1 (en) Packet transmission apparatus, communication system and computer-readable recording medium
EP1309122A2 (en) Apparatus and method for data communication with retransmissions
US9781488B2 (en) Controlled adaptive rate switching system and method for media streaming over IP networks
US20110044338A1 (en) Throughput in a lan by managing tcp acks
EP1328096A2 (en) Multimedia data packet communication with data type identifiers
KR20120082416A (en) An efficient application-layer automatic repeat request retransmission method for reliable real-time data streaming in networks
JP2001274861A (en) Method and device for data transmission
JP5117512B2 (en) Method and apparatus for dynamically adapting the number of retransmissions
CN106100803A (en) The method and apparatus determined is retransmitted for making
EP1450535A1 (en) A relay for hierarchical retransmissions in multimedia streaming
EP1947859A1 (en) Video transmission method and system
Rossi et al. A partially reliable transport protocol for multiple-description real-time multimedia traffic
Zhai et al. Elements of a Video Communication System

Legal Events

Date Code Title Description
AS Assignment

Owner name: THOMSON LICENSING, FRANCE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LU, XIUPING;MANDREKAR, ISHAN UDAY;PERUMANAM, RAMKUMAR;AND OTHERS;SIGNING DATES FROM 20100212 TO 20100217;REEL/FRAME:032526/0421

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION