Comp61232: Mobile Comms - School Of Computer Science | The

Transcript

18/03/2014 CD quality digital audio University of Manchester • Humans can hear sound over a frequency range 20 Hz to 20 kHz School of Computer Science – over a dynamic range of 120 dB – 10log10(loudest /quietest) Comp61232: Mobile Comms • To obey ‘Sampling Theorem’, sampling freq > 40 kHz – We take Fs = 44.1 kHz B3: VOICE • For 120 dB, need  20 bits – too many when CDs were invented. – Settled for 16 bits per sample. • CD data rate (stereo) = 16 x 44,100 x 2 = 1,411 kbit/s Barry Cheetham 17/03/14 COMP61242: B3 1 Fixed telephone quality digital speech • Band-limited from 300 Hz – 3.4 kHz – narrow-band. (or 50 Hz – 3.4 kHz) • Loses naturalness but not intelligibility (in principle) • In practice, sometimes cannot distinguish “S” from “F”! • Sampled at Fs = 8 kHz with 8 bits per sample • 64 kbit/s bit-rate, but needs non-uniform quantization 17/03/14 COMP61242: B3 2 Speech coding for mobile phones • 64 kbit/s too high for mobile phones. • Originally, they used 24.7 kbit/s , but this included extra bits for correcting bit-errors. • Bit-rate available for narrow-band speech  13 kbit/s. • More recently, AMR speech coder is used. • Encodes narrowband speech at bit-rates ranging from 4.75 to 12.2 kbit/s. • ‘Toll’ quality speech is achieved at 12.2 kbit/s. – mu-law or A-law – known as the ITU-G711 standard • How? 17/03/14 COMP61242: B3 3 17/03/14 COMP61242: B3 4 An idea: differential encoding The problem • If sampling rate (Fs) is 8 Hz, • Encode differences between samples: – only have 1.5 bits per sample at 12 kb/s. • If we reduce Fs to 4 kHz, s[n] e[n] – we must filter off all sound above 2 kHz. Quantiser Transmit or store • Speech will sound ‘muffled’ • And even then, we will have only 3 bits/sample, Delay by 1 sample – Still not enough with uniform sampling. s[n-1] • It works at bit-rates of 32 & 16 kbit/s. • Still not low enough for mobile phones. 17/03/14 COMP61242 - B3 COMP61242: B3 5 17/03/14 COMP61242: B3 6 1 18/03/2014 Human speech production: voiced 2. Parametric speech coders • Air-flow causes vocal cords to open & close periodically. • Causes pressure variation (sound). • Modified (filtered) by vocal tract to produce vowel sound. • So far, all our ideas have tried to encode the shape of the signal (its ‘waveform’) by sampling it. • These are ‘waveform coders • Simple, but no good at very low bit-rates. • Parametric coders try to model the human speech production process: Speech waveform Time –the vibration of the vocal cords, and –the shape of the ‘vocal tract’ (mouth, lips etc) • These do not change as quickly as the wave-form • So can be sampled more slowly without losing accuracy. Pressure Pressure variation at vocal cords Vocal cords T 17/03/14 COMP61242: B3 7 Human speech production: unvoiced • Vocal cords held open – no vibration. • Constriction in air-flow creates ‘turbulence’. • Turbulent flow is chaotic & random – sounds like white noise waveform for consonant t Nose 17/03/14 Noise generator Digital filter Vocal tract model Speech output Coefficients Air from lungs 9 17/03/14 COMP61242: B3 10 LPC-10 • 2400 bit/s coder once widely used in military comms. • Not used in mobile phones • Encodes 20 ms speech frames by deriving: – 10 digital filter coeffs by LPC analysis, – unvoiced/voiced decision (1 bit) – gain (or amplitude): a single number: 8 bits say – fundamental frequency: a single number: 8 bits say) • Each frame has 48 bits which affords 37 bits for the 10 digital filter coeffs. • Quite simple to understand and implement, • But its quality is far from good (run & listen to demo) Coeffs of a digital filter which models effect of the vocal tract How loud it the speech is Whether it is voiced or unvoiced If voiced, measures the fundamental frequency • These parameters are sent to represent the speech. • Receiver reconstructs speech from these parameters. COMP61242 - B3 Amplifier Gain Vocal cords COMP61242: B3 Switch Fundamental freq • Similar model implemented in all mobile phones. • Sender & receiver • Sender derives parameters every 20 ms (50 times/s): 17/03/14 Air from lungs 8 Model of human speech production Linear predictive speech coding (LPC) – – – – Time Voiced or UnV t COMP61242: B3 COMP61242: B3 Impulse sequence generator Mouth Tongue Pressure variation at constriction 17/03/14 Nose Mouth Tongue 11 17/03/14 COMP61242: B3 12 2 18/03/2014 LPC10 demo in MATLAB LPC10, CELP & AMR • Simple LPC10 encoder & decoder written in MATLAB. • Encoder (BLPC10encoder.m) derives filter coeffs & vocal tract excitation for 20ms segments. – Voiced’ & ‘excitation freq’ determined by very simple method – Stores parameters in a file ‘LPCparams.bin’ • Decoder (BLPC10decoder.m) implements the model • LPC-10 coder at 2400 b/s used in military comms. • Another form of LPC is codebook excited LPC (CELP) • Used in mobile telephony (13 kbit/s & lower). • Adaptive multi-rate (AMR) coder uses CELP at various bitrates: – uses parameters read from LPCparams.bin • Run the encoder, but don’t worry abt how it works yet. • Then run decoder, & modify MATLAB code to investigate: – what happens if the speech is always forced to be unvoiced? – what happens if it is forced to be voiced with a constant pitch- 4.75 … 7.4 , 7.95, 10.2, 12.2 kbit/s • Uses vector (code-book) quantisation. • Better quality than LPC10. period of 40 samples? 17/03/14 COMP61242: B3 13 Codebook excited LPC (CELP) COMP61242: B3 14 15 • Waveform coding techniques such as PCM & ADPCM try to preserve exact shape of waveform as far as possible. • Simple to understand & implement, but cannot achieve very low bit-rates. • Parametric techniques such as LPC10 & CELP do not aim to preserve exact wave-shape. • Instead they represent features expected to be perceptually significant by sets of parameters, i.e. by filter coeffs & params of excitation signal. • Parametric more complicated to understand & implement than waveform coding, but achieves lower bit-rates. 17/03/14 COMP61242: B3 16 Voice over ‘4G’ 4. Fixed & mobile phone networks • LTE standard supports only IP packet switching. • 4 ways of handling voice are being discussed • Voice over LTE (VoLTE) • Originally designed to carry speech. – – – – – COMP61242: B3 3. Waveform & parametric coding. • Instead of having fixed noise & impulse-generators, CELP model has a selection of different ones stored in a code-book. • Sender tells it which ones to use for each frame. • Just needs to send a code-book index. • Sender has a copy of the code-book & uses ‘analysis-by synthesis’ to find the best excitation to use. • Tries them one-by one & compares what they produce with the original speech. 17/03/14 17/03/14 Circuit switched From 2G till now, speech is digitised by LPC. Low delay Seamless hand-over etc. – Voice service delivered as data flows within the LTE data flow. – No need for legacy Circuit Switch voice networks to be maintained. • Circuit-switched fallback (CSFB) • From ‘4G’ onwards phones will move to IP data networks. • What will happen to speech is still under discussion. – LTE just provides data services, – Voice calls fall back to the circuit switched domain. • Simultaneous voice and LTE (SVLTE) – Phone works simultaneously in LTE & circuit switched modes. – LTE mode for data & circuit switched mode for voice. – Distinction exists only in the phone. • ‘Over-the-top’ (OTT) content services – Use VoIP apps like Skype to provide voice over LTE IP network. – Voice is still main revenue source, so this is not likely. 17/03/14 COMP61242 - B3 COMP61242: B3 17 17/03/14 COMP61242: B3 18 3 18/03/2014 VoLTE 5. Fixed & mobile IP networks • Originally designed for data. • Packet switched. • Soon adapted to real time interactive telephony (VoIP) • VoLTE is definitely the future, • Must to be able to smoothly handover to a 3G or 2G network to maintain quality under adverse conditions. • Demand for voice calls today has led LTE carriers to introduce ‘CSFB’ as a stopgap measure. – As well as data – Sometimes with more than ideal latency. • Digitised speech split up into packets – When placing or receiving a voice call, LTE smartphones will fall back to old 2G or 3G networks for the duration of the call. – Each packet may contain 20 ms or 160 samples – Send 50 packets per second in both directions • Useful to mention 2 transport layer protocols: – TCP – UDP 17/03/14 COMP61242: B3 19 17/03/14 – – – – – – • • • • ‘Fire and forget’ Widely used for real time VoIP for several reasons: Cannot wait for ‘ack’s & retransmissions Increased congestion unacceptable. Voice not as sensitive as data to bit-errors & ‘lost packets. Redundancy in speech allows Packet Loss Concealment. 17/03/14 COMP61242: B3 • • • • • • • 21 UDP introduces some problems. Packets may be lost, irreparably damaged or re-ordered, Receiver must know when this happens. Useful for transmitter to know how many of its packets are getting through & with what delay variation. Facilities provided by RTP & RTCP. Described in RFC1889 & Tanenbaum textbook. RTP adds a ‘time-stamp’ to payload of a UDP packet. Allows need for PLC to be recognised at receiver. Duplicate packets must be recognised & eliminated. RTCP sends reports to transmitter every 5 s or so General idea of percentage of lost packets & jitter. 17/03/14 7. Jitter & lost packets in VoIP • • • • • COMP61242 - B3 COMP61242: B3 COMP61242: B3 22 Illustration Jitter-buffer at receiver allows for variation in delay. If all packets delayed by 0.1 s, no jitter-buffer needed. Assume 1-way delay varies between 0.02 & 0.12 s, Jitter-buffer of size 0.1 s to avoid ‘data under-flow’; i.e. running out of data while waiting for delayed packet. 17/03/14 20 RTP & RTCP 6. Transport layer protocols, TCP & UDP • TCP is connection-oriented, ‘reliable’ & suited to data. - Uses acknowledgements & retransmissions - Unsuitable for real time interactive VoIP. • UDP is simpler, connectionless & ‘unreliable’. COMP61242: B3 23 • Consider an example where voice is sampled at 8 kHz with 8 bits (1 byte) per sample. • This could be ‘G711’ or ’64kb/s A-Law PCM’ speech as commonly used in wired telephony & VoIP. • Assume we send 20 ms packets each with 160 bytes. • Assume we introduce a 100 ms jitter buffer. • This can store up to 5 packets. • Introduces 100 ms delay. 17/03/14 COMP61242: B3 24 4 18/03/2014 0.1 s jitter-buffer with 0.02 s (160 byte) packets What happens next? – consider 2 possibilities 1. Wait till we’ve got 5 VoIP packets – store in buffer 6. Four late packets arrive at once – no problem – buffer restored 160 2. Send 1st 160 160 160 160 packet to sound card 160 160 160 160 160 160 160 160 160 OR 160 160 6. Another 0.02 s & still no VoIP packet arrives – buffer now empty 160 160 4. If next VoIP packet is late, buffer reduces in size 160 160 Output 160 3. Hopefully receive next VoIP packet & refill buffer 160 160 160 7. Another 0.02 s & still no VoIP packet – buffer underflows - BAD 160 ? 160 5. Another 0.04 s elapses with no sign of next VoIP packet 160 Sound card must be fed – otherwise it crashes. 160 So have to invent a VoiP packet - PLC 17/03/14 COMP61242: B3 25 17/03/14 Jitter & delay COMP61242: B3 26 Jitter-buffer size • Receiver’s jitter-buffer introduces delay & affects number of packets ‘lost’ due to excessive delay. • Increasing buffer size decreases no. of lost packets in a wired VoIP link at expense of increasing delay. • Round trip delay > 300 ms makes conversation difficult. • Limits delay that can be introduced at each receiver. • Assume propagation delay is 30 ms, & payload is 160 bytes (20ms) • 2 ×50 ms used up • Capacity for 100 ms buffers at each end of 2-way link. • Reservoir of 800 bytes or 5 packets. • Receiver has no way of knowing actual 1-way delay. • Delay variation from 0.05 to 0.15 gives same jitter. • Packet arriving too late to avoid underflow is ‘lost’. • With wired networks, most ‘lost’ packets are just late. • Packets rarely undelivered or damaged. • Not true for wireless/mobile networks. 17/03/14 COMP61242: B3 27 17/03/14 Question for you COMP61242: B3 28 8. Mobile OTT-VoIP • Having set up such a VoIP link how could you improve it if RTCP reports zero lost packets at one end & 10% at the other? • OTT-VoIP means systems like SKYPE that run over IP networks. • Even with wired networks, OTT-VoIP mobility is provided by SIP. – SIP is ‘session initialisation protocol’ – Location server informed where you are when you register. – Voice streams then sent to & received from your current IP address. • Mobile VoIP can also mean the application of OTT-VoIP to smartphones. – Cheaper alternative to the cellular network – OTT-VoIP over Wi-Fi referred to as VoWiFi or VoWLAN. – Since WLANs support IP, UDP & TCP, they can support VoWiFi. • SIP protocol works on WiFi connected devices. • However some interesting issues arise with OTT-VoIP over WiFi. 17/03/14 COMP61242 - B3 COMP61242: B3 29 17/03/14 COMP61242: B3 30 5 18/03/2014 8.1. Quality of Service (QoS) issues 8.2 Congestion issues • Characteristics of WLANs different from those of wired LANs. • Damaged packets rare with wired networks & common with wireless. • Although data-link layer tries to produce error free packets with use of FEC & ARQ, irreparably damaged packets & packets that are truly lost occur more frequently than with wired networks. • Use of ‘fire & forget’ protocols means that speech quality cannot be controlled at transport layer. • May be rather different & more variable with Voice over WiFi than with VoIP over wired networks. • Network congestion over contention-mode WLAN is problem with several VoIP users, especially when there are data users as well. • WLAN capacity & radio bandwidth is limited resource • Regular access required by VoIP makes heavy demands. • VoIP packets must be short to achieve the required latency. • Payloads < 200 bytes & a lot less when compression employed. • With G729 at 8kb/s, 30 ms of speech requires only 30 bytes • Packets containing 30 bytes sent regularly at 34 per second. • Overheads of RTP, UDP, IP, 802.11 MAC headers & synch bits at phy layer make payload a small proportion of each frame. 17/03/14 17/03/14 COMP61242: B3 31 COMP61242: B3 Illustration 32 Illustration as diagram • Phy-layer synch & PLPC header with IEEE802.11b frame takes 200 s in addition to payload. • 1000 bytes of text, increased to 2000 bytes by FEC, takes 2 ms to transmit at 11 Mb/s, so overhead is about 10%, • 100 bytes sent in 0.2ms, phy layer overhead becomes 100% . • For 30 bytes, framing overhead approaches 300%. • VoIP begins to appear rather inefficient. • Increasing packet size not an option with interactive VoIP. • If data link layer retransmissions become necessary because of collisions & radio noise, inefficiency becomes worse. • A single un-correctable bit-error causes whole packet to be discarded and a repeat transmission to be requested. Pre-amble + header 1000 bytes of text 0.2ms 2 ms 100 bytes (12.5 ms of G711speech)  0.2 ms 30 bytes (30 ms of G729 compressed speech)  0.06ms 17/03/14 COMP61242: B3 33 Number of VoIP users on a WLAN • • • • • • • • COMP61242 - B3 COMP61242: B3 COMP61242: B3 34 8.3. Coverage/handover issues Up to 10 retransmissions before packet considered ‘lost’. Sustainable on a lightly loaded WLAN.  8 VoIP users on 802.11b WLAN render it unusable,. Total payload loading with eight ‘2-way’ G711 coded VoIP calls would be 8x2x64k = 1.024 Mb/s. 10% of bit-rate capacity under ideal conditions. Surprising that we can get 8 calls over 802.11b. For ‘wireless office’ this limitation would be a problem. Also lack of control over unlicensed radio spectrum. 17/03/14 17/03/14 35 • VoWiFi used in hospitals where mobile phones are banned. • Require many access points. • With ‘seamless’ horizontal handover from one AP to another. • Also ‘seamless’ vertical handover to a cellular network. • Not easy 17/03/14 COMP61242: B3 36 6 18/03/2014 8.5 Non-contention mode 8.4. Power consumption issues • Battery powered WiFi enabled phones give mobility. • Battery usage ‘talk time’ & ‘standby time’ are vital issues. • Cost of transmitting & receiving bits over radio must be considered in terms of channel capacity & energy consumption. • Energy cost of processing messages & ‘standing by’ also vital issue. • IEEE802.11 standards allow devices to ‘sleep’ to save energy. • VoIP systems need to be able to do this between transmissions. • With CSMA, media access is granted at varying intervals of time. • Difficult to sleep in intervals between successive speech packets. • CSMA requires radio medium to be sensed more or less continually. • Energy costs of retransmissions due to collisions may be high. 17/03/14 COMP61242: B3 37 • Always provided by IEEE802.11 as alternative to CSMA. – – – – – – Access point acts as a central controller Uses ‘polling’ by sending ‘beacons’ at regular intervals Tells each device when to receive/transmit. VoIP system could send polling beacons at intervals of 20 ms. Devices could sleep for 19 ms until next beacon is expected. Spec not ideal & probably never used. • Problems fixed with IEEE802.11e, 802.11n & WME • Has other features useful for QoS apps including VoWLAN. 17/03/14 IEEE802.11e, n & WME COMP61242: B3 8.6 Speech digitisation issues • IEEE802.11e is extension to 802.11a for 5GHz band. – Never legally used in the UK. – Reduced range makes 5 GHz band less attractive for ‘hot-spots’. G711 widely used for VoIP & lower bit/rate coders available for ‘narrowband’ (300-3400Hz) telephone quality speech sampled at 8kHz. Coding Quality Proc delay Processing Memory complexity of errors b/s • Facilities of 802.11e now provided by 802.11n at 2.4 GHz. – Also provided by WME (Wireless Multimedia Extensions) • Can arrange that devices only transmit & receive at regular times as scheduled by APs. – Guaranteed free channel for transmission – Contention is eliminated. • Channel used efficiently & more VOIP users are possible. • All IEEE802.11 devices will be compliant with 11n. 17/03/14 COMP61242: B3 39 Raw 16 bits v high none none none 128k G711 high none low none 64k G726 high low medium some 32k G728 high low high high 16k G729 high high high high 8k G723.1 lower high high high 5.3kb/s 17/03/14 9. Mean opinion score (MOS) • • • • • Voice quality Level of distortion 5 Excellent Imperceptible 4 Good Just perceptible but not annoying 3 Fair Perceptible & slightly annoying 2 Poor Annoying but not objectionable 1 Bad COMP61242: B3 40 MOS for speech coders Gold standard for measuring voice quality, i.e. ‘listening quality’ Carefully controlled listening experiments with human subjects. Correct acoustical environment & randomised volunteers, Extremely time-consuming & expensive. Human listeners classify voice quality into categories: Rating 38 • • • • Averaging produces scores on continuous scale between 1 & 5. Average of 4.0 or higher is ‘toll quality’. Such quality provided by A-law PCM (G711) at 64 kb/s. MOS scores for standard bit-rate compression schemes are: Bit-rate compression method Bit-rate (kbit/s) MOS score G711 ‘A-law PCM’ 64 4.4 G726 ‘ADPCM’ 32 4.2 22.8 4.0-4.1 G728 ‘Low delay CELP’ 16 4.2 G729 CS-ACELP 8 4.2 5.3 3.5 GSM mobile link in ideal conditions Very annoying and objectionable G723.1 ACELP • Averaging applied to produce final ‘MOS score' 17/03/14 COMP61242 - B3 COMP61242: B3 41 17/03/14 COMP61242: B3 42 7 18/03/2014 PESQ 10. Effect of packet-loss on speech quality • • • • • • MOS scoring expensive & assesses only listening quality. • PESQ is objective method of deriving MOS-type scores. • Perceptual Evaluation of Speech Quality • ITU-T standardisation committee P862 • International Telecommunication Union – Telecommunications Standardisation Bureau (ITU-T) Increasing packet loss rate causes voice quality to decrease. Often assumed that up to 5% loss acceptable. Assumption poorly reflects true effect of packet loss. Estimate of effect of packet loss on MOS scores given below G711 with 20 ms frames & PLC. . Effect of packet loss 5 MOS 4 3 2 1 0 17/03/14 COMP61242: B3 43 • PLC uses predictability in speech waveforms. • Allows guesses about what is likely to come next. • Works well for voiced sounds: quasi-periodic. • If dashed part lost, similarity with what came before makes it possible to produce a reasonable replacement. • Demo (30% PL): Zero stuffing: 45 17/03/14 ‘Why not forget about the missing packet & go on with next one?’ ‘Just miss it out?’. OK for a file of music? With a video sound track, you may lose lip-synchronisation. Disastrous for telephony because of ‘real time’ requirement. No. of samples sent must be no. of samples received Otherwise receiver’s jitter-buffer runs out & generates a ‘click’. Expect small differences in sampling rates at transmitter & receiver Crystal controlled clocking accurate to 1 part in 104 May be a difference of  1Hz in 8000Hz. In 2-way VoIP session lasting 10 mins, may send 600 more samples than receiver can deal with. • Jitter-buffer grows & eventually overflows. • Also 600 too few samples will be sent back causing underflow. COMP61242 - B3 44 Repetition: COMP61242: B3 46 Solution 11.2 Some finer points of ‘real time’ • • • • • • • • • • COMP61242: B3 5 Obvious idea is just to repeat the previous frame, Works perfectly in previous example. Much better than ‘zero stuffing’. Simple packet repetition will not always work so well, Wave-shape & its periodicity will be changing Any discontinuity as reconstructed frame joins onto next frame will produce a nasty ‘click. • Need something a bit more sophisticated • Provided by Appendix 1 to the ITU-G711 standard. t 17/03/14 4 COMP61242: B3 • • • • • • Volts COMP61242: B3 2 3 % loss (20 ms packets) Simple frame repetition 11. Packet loss concealment strategies 17/03/14 1 17/03/14 47 • Dealing with this sampling rate asynchrony without generating audible clicks is a nice problem. • Simplest approach is to: – Monitor average jitter-buffer size. – Feed in or extract an odd sample now and then, making sure that this will not cause a click. 17/03/14 COMP61242: B3 48 8 18/03/2014 11.4. Comparison of strategies • • • • • • • • • • • Hides effects of lost packets. ‘C’ function & converted to MATLAB for evaluation. Delays speech by 3.75 ms. When packet lost, previous speech analysed to determine periodicity. Pitch cycle extracted & copied repeatedly for duration of lost packet. Smoothing at frame boundaries to avoid any discontinuities. If successive packets are lost, gradually ramp down in amplitude. ‘High quality’ & ‘low complexity’ for G711encoded speech. About 0.5 MIPs with 10 ms frames. May be adapted to different frames sizes, say 20 ms. With 10 ms packets, achieves MOS score of 3.4 with 5% packet loss. • • • • • Figure below compares ITU-G711 PLC scheme with others. Packet size is 10ms. For toll quality, 2% packet loss may be tolerated with ITU-PLC MOS > 3 safely maintained with packet loss-rates up to 5%.. ITU-T G711 PLC rather better with 10ms packets. 5 Comsat measurements 4 Zero stuff MOS 11.3. ITU-T-G711 Appendix 1 PLC Packet rep 3 ITU PLC GIPS GIPS enhanced 2 % packet loss 1 0 17/03/14 COMP61242: B3 49 17/03/14 11.5. Question 5 10 15 20 25 30 COMP61242: B3 11.6. IntServ & Diffserv • An end-to-end VoIP over WLAN uses 50 ms G711 speech frames, zero stuffing PLC and.. • It delivers an MOS score of about 2.5, round trip delay of 200 ms and frequently crashes due to network congestion. • What steps could you consider to improve the performance of this WLAN link and which ones would you use? • What steps would be appropriate if the were a wired link? • Reservation of transmission capacity priority for certain traffic. • VoIP widely used over wired networks with reserved capacity • See notes 17/03/14 17/03/14 COMP61242: B3 51 VoIP for interactive real time telephony & streaming. Requires regular transmission of packets with latency limits. ‘Fire & forget’ transport layer protocols via RTP, RTCP RTSP & SCTP. H323 & SIP for setting up maintaining & tearing down calls. No QoS guarantees: jitter & lost packets occur. Mobility via ‘mobile IP’ & WLANs (VoWLAN or VoWiFi) Wired & wireless networks have different QoS. VoWiFi requires coverage with handover. Congestion & power control issues arise. Bit rate compression at expense of complexity, delay & quality. Non-contention mode (802.11e/n) beneficial. Speech quality assessed by MOS & E-model Principles of PLC algorithms discussed & illustrated for VoWiFi. 17/03/14 COMP61242 - B3 COMP61242: B3 COMP61242: B3 52 13. Problems & discussion points 12. Conclusions & learning outcomes • • • • • • • • • • • • • 50 53 1.Since IP was designed primarily for data why is it being used for VoIP? 2. Why is VoIP telephony more demanding than streaming? 3. What are the advantages & disadvantages of employing speech bit-rate compression in (i) VoIP and (ii)VoWiFi? 4. What would you expect to happen at the MAC layer when an 802.11b/g WLAN becomes congested with say 9 VoIP users? 5. Why are mobile VoWiFi devices traditionally so power inefficient? 6. Two mobile VoIP devices with different speech sampling rates, 8000 & 8010 Hz, are communicating 20ms (G711) packets over a WLAN. How could you avoid distortion due buffer under- and over-flows. 7. Why was ‘PCF’ IEEE802.11 non-contention mode never used? 8. Can VoIP & data co-exist on a WLAN? What problems can occur & what solutions have been proposed? 17/03/14 COMP61242: B3 54 9 18/03/2014 Problems & discussion points (cont) 9. Explain the difference between horizontal & vertical handover. 10 What is meant by ‘seamless’ handover for VoIP users. 11. To what extent does MOS reflect the perceived (subjective) quality of a VoIP link and why do we need objective assessments & the ‘E-model? 12 Suggest one or two changes that could be made to the IEEE802.11 MAC layer to make it more efficient for VoIP. 17/03/14 COMP61242 - B3 COMP61242: B3 55 10