Lecture 9 and 10 Source coding for packet networks
Outline Motivation/situation Source coding (representing the same information with less bits) (extremely short intro) Packet losses: - Packet loss measurements on the Internet - Gilbert-Elliott loss model Humans experiencing delay and distortion New error correction schemes: - Layered coding -Multiple description coding -Correlated source variables: Error concealment, interleaving Jitter Synchronization Standards for multimedia
Question to be dealt with Application layer We do not want to send unnecessary data for our application => new concept: source coding (representing the same information with less bits) The network leads to packet losses (congestion, router packet drops) and delay How do we handle this?
Skype We have recently run a project together with Skype on this, see Henrik Cooke, "Implementation and evaluation of packet loss concealment schemes with the JM reference software", master thesis, http://www.diva-portal.org -modeling Internet packet losses, interleaving, error concealment, delay, synchronization, Other concepts were also discussed thoroughly: multiple description and layered coding
Video example Application layer Source coding MPEG4 AVC Storage, e.g., harddrive Error control Channel The TCP/IP protocol suite spans all these boxes Application layer Source decoding Error control
Source coding (extremely short intro) Sample a time-continuous, continuous-amplitude signal. Speech, music, video, sensor readings Lossy source coding: Discrete time continuous amplitude signals: Round off amplitudes to discrete values- quantization Text Lossless source coding: Bit sequences representing amplitudes: Shorten these sequences. See whiteboard!
Lossy source coding - quantization: noninvertible Lossless source coding: invertible
Source coding example lossy: the message cannot be recreated perfectly. Original Joint Photographic Experts Group (JPEG) reconstruction, ¼ of the number of bits describing the original
Lossy source coding example Original Joint Photographic Experts Group (JPEG) reconstruction, 1/25 of the number of bits describing the original
Packet loss measurements on the Internet J. Bolot, Characterizing end-to-end packet delay and loss in the Internet, Journal of High-Speed Networks, 1993: Packet losses are independent if the traffic uses a small fraction of the available bandwidth V. Paxson, End-to-End Internet Packet Dynamics, IEEE/ACM Transactions on Networking, 1999: An order of magnitude difference in packet loss probability if the foregoing packet was lost M. Yalnic et al., Packet loss correlation, in the Mbone multicast network, GLOBECOM Conference, 1996: A majority of the losses occurs independently, but some very big bursts of losses were observed. Most losses are on access networks. Network settings are different. Difficult to draw conclusions. However, both independent losses and loss bursts seem to be important to model
Loss bursts: The Gilbert-Elliot model See overhead!
Humans experiencing distortion If some words are lost, a text is impossible to understand. Similarly for a photo album image For speech and video, some lost data could be accepted by users It is difficult to come up with a mathematical distortion measures corresponding to how humans experience speech, audio, and video distortion. Mean square error is commonly used, but does not correspond that well in all applications Spotify: problems can occur three times during a session, quite long ok but not more than 3 times!
Summary of types of delay Processing delay: by various software and hardware. Becomes smaller with fast software/hardware Propagation delay: The time it takes to propagate a signal over the network. Limited by the speed of light, Propagation time= distance/(propagation speed) Transmission delay: Transmission time= (nr of bytes to send)/(transmission speed) Algorithmic delay: Algorithm limitations, e.g.: - We collect a number of bits into a longer message and pass it down the IP stack. Even with very fast computers, this delay cannot be avoided. We can choose other algorithms though. - TCP ARQ delay
Humans experiencing delay A text chat is not sensitive to delays one-way of 400 ms A speech/video real-time conversation cannot tolerate large delays <150 ms one-way good, 150-400 acceptable, >400 bad. International Telecommunication Union (ITU) considers network delay for voice applications in Recommendation G.114.
TCP and UDP usage real-time speech/video conversation: tolerate distortion but not delay Transport layer TCP is reliable (all packets are delivered, and in order) but retransmissions cause delays => do not use TCP Use UDP! possibly complement with some other application layer strategy. text-applications: tolerate delay, but no distortion Use TCP!
FEC A packet holds many bytes. A FEC strategy is to copy the bits describing a quantized sample in two UDP packets (repetition code).
Multiple description coding and layered coding Multiple description coding: Send several packets that can be decoded separately if one packet is lost, or together to get better quality, if all packets are received (error control). Layered coding: Users with poor channels only get the basic layer/packet, but some users with better networks receive extra layers/packets improving the service quality (congestion control). See whiteboard!
FEC/Multiple description coding/layered coding and the Gilbert-Elliott model
Other strategies than ARQ and FEC: Error concealment Use correlation in the data after source coding to interpolate over lost data at the receiver side. See my journal papers from 2009-2010: http://www.commsys.isy.liu.se/en/staff/danielp See whiteboard!
Video error concealment examples See movie examples!
Packet jitter Delays may vary a little all the time within the same stream, because router queues vary Delays that vary with each packet are called jitter. Use a jitterbuffer and delayed playout, so delayed packets are given a chance to catch up, and do not have to be considered lost. Jitter buffers with too long playout delay threaten real-time applications. There is thus a tradeoff between jitter buffers and delay!
Time stamps, sequence numbers and synchronization info Sequence numbers => we know if a packet is lost Time stamp => we know when to play out a packet even with variable length coding if previous packet lost For video (3D data) with variable length coding, we need extra synchronization info to understand at the receiver where to play out a packet in the image/video frame even if previous packet lost.
Synchronization See overhead notes!
Protocols supporting multimedia TCP has sequence numbers and time stamps. We know that TCP ARQ gives delay, and is therefore not suitable for video conversations. UDP does not use retransmissions, and is therefore suitable for video conversations. It does not have time stamps and sequence numbers. How can we complement it? One solution is the Real-time Transport Protocol (RTP). Each RTP packet is encapsulated in a UDP packet. The RTP header includes time stamp and packet sequence numbers. Real-Time Transport Control Protocol (RTCP): statistics for RTP sessions, answering, e.g., how many packets were lost. It is up to the application developer what to do with this info. H.323 (ITU) / Session initiation protocol (SIP) (IETF): Standards for computer to computer/pstn communicaton. Both work with video and speech H.323: Umbrella standard for both control and data transfer, uses RTP SIP: Only control, works with RTP, but not mandatory
Future of the networks? We started out in the first lecture with a time line of the Internet, which only has been around for around 30 years. How will Internet look 30 years from now? Some questions are for example: Can the self-deployable WIFI networks replace LTE to a larger extent? Will IPv6, with its label field, give rise to a connection-based network layer, so that we will have the same service as in PSTN? When will good multicasting strategies be used in practice? How will the increasing demand for wireless access be met in the future? What new data mining applications will there be?
Exam...
Master thesis 1 Today's Terrestrial trunked radio (TETRA) is an ETSI standard used in more than 110 countries worldwide for first responders. TETRA sensitive to jamming. CONNECTED: FOI, Stockholm Fire Department, Stockholm Police Department, SOS Alarm, Swedish National Task Force, the Swedish Fortification Agency, Sjöland & Thyselius, Swedish military P. Stenumgaard, D. Persson, K. Wiklundh, E.G. Larsson, ''An Early-Warning Service for Emerging Communication Problems in Security and Safety Applications``, IEEE Communication Magazine, 2012.
Master thesis 2 Wireless communication algorithms taking power amplifiers into account Throughput MRT Total consumed power (db) LiU CENIIT project 2013
Please take the time to do the course evaluation!