Improving Communication Quality with Reed Solomon Code in Internet Voice Broadcasting System

1. Improving Communication Qualitywith Reed Solomon Codein Internet Voice Broadcasting System Shingo Kashima Kyushu University, Japan Asia-Pacific Advanced Network 2003 January 21-24, 2003 Fukuoka, Japan

2. Plan of Presentation • Background (Existing Issue) • Objective • Icecast • Solution of Issue • FEC and Reed Solomon Code • Proposal of System • Evaluation • Future Work • Summary

3. Background [1 of 2] • Music Delivery in Real Time • 1 to 1 communication using client-server model

4. Modify existing applications • Expensive Background [2 of 2] • Issues in the Current Model • A heavy load is applied at the network between client and server. • The number of clients is limited by bandwidth of network between client and server. • Sound is interrupted or noise occurs. • Solution

5. Objective • Improve the communication quality ofa large scale real time voice broadcasting on the Internet without modifying the existing applications.

6. Icecast • Audio streaming server • Developed under the GNU General Public License • Support MP3, HTTP / TCP • Support many client applications • ex. WindowsMediaPlayer, Winamp, XMMS, etc • Relay function (described later)

7. Issues in the Current Model • A heavy load is applied at the network between client and server. • The number of clients is limited by bandwidth of network between client and server. • Sound is interrupted or noise occurs.

8. Issues in the Current Model • A heavy load is applied at the network between client and server. • The number of clients is limited by bandwidth of network between client and server. • Sound is interrupted or noise occurs.

9. m n n m n n×m Solution of Issues I, II • Distributed Delivery by Relay Server • The load of network is reduced. • The number of clients increases.

10. Issues in the Current Model • A heavy load is applied at the network between client and server. • The number of clients is limited by bandwidth of network between client and server. • Sound is interrupted or noise occurs.

11. Delay by Retransmission of TCP • TCP ･･･ Transmission Control Protocol Solution of Issue III [1 of 5] • Factor of Issue III

12. Ack nowledgement Ack nowledgement Ack nowledgement Ack nowledgement Ack nowledgement Ack nowledgement Solution of Issue III [2 of 5] • The Communication with TCP Client has received the packet.

13. LOSS! Solution of Issue III [3 of 5] • The Communication with TCP Ack nowledgement ?? Ack nowledgement ?? Ack nowledgement ?? Ack nowledgement ?? Ack nowledgement ?? When a packet is lost.

14. Solution of Issue III [3 of 5] • The Communication with TCP No ack nowledgement! Retransmission When a packet is lost.

15. Buffer data at clients • Replace TCP with UDP in transport layer • UDP has no Retransmission Control • UDP ･･･ User Datagram Protocol Solution of Issue III [4 of 5] • Delay by Retransmission Control of TCP

16. Need to guarantee for packet loss in application layer • FEC (Forward Error Correction) • FEC resotores lost packets Solution of Issue III [5 of 5] • UDP is not reliable for arrival of packet

17. FEC × × × Burst Error Reed Solomon code

18. × × errors divide into 4 blocks every 4 bits encode correct 2 error blocks Reed Solomon Code • 4bit (8, 4) RS code available in the network with knowing packet loss rate

19. little packet loss little packet loss little packet loss much packet loss Do not modify applications Proposed System Proposal of System [1 of 4] • Provide Gateways Existing System

20. RS code/UDP HTTP/TCP HTTP/TCP HTTP/TCP HTTP/TCP RS decoding RS code/UDP RS encoding UDP→TCP TCP→UDP HTTP/TCP HTTP/TCP HTTP/TCP RS decoding UDP→TCP Proposal of System [2 of 4] • The Stream of Sound Data

21. Proposal of System [3 of 4] • RS encoding and division into packets

22. Proposal of System [4 of 4] • Packet Format • block number • position of the packet • number in a block • position of the packet in a block • real data size • date size of a block brefore encoding(generally 4096 bytes)

23. Evaluation [1 of 5] • Compare the communication quality in the proposed model with the existing model • Interruption and Noise • Connect-able Time

24. mesure connect-able time listen to noise or interruption Evaluation [2 of 5] • Evaluating environment • server ･･･ Internet Radio Station FOR (in IPU) • router ･･･ 20 • MP3 bitrate ･･･ 32kbps • Reed Solomon code ･･･ 8 bits (32, 16) RS • packet loss rate ･･･ unknown

25. less interruption and noise Evaluation [3 of 5] • Interruption and Noise experimental time : 300 seconds

26. more difficult to disconnect Evaluation [4 of 5] • Connect-able Time(connection between client and relay server) • Existing model • 5 minutes at the worst • proposed model • never disconnect (300 minutes)

27. Evaluation [5 of 5] • Interruption and Noise • decreased • Connect-able Time • increased Communication quality improved in the real network without knowing packet loss rate.

28. Future Work • Value-added services provided between a server and relay servers • bitrate conversion for bandwidth constraint environment (ex. PHS, mobile user) • different Commercial Message for each relay server Value-added Servive

29. Summary • The issue of Interruption and Noise • UDP and Reed Solomon code • Provided gateways using Reed Solomon code into the existing system. • Not modify the existing applications. • The communication quality improved in the proposed system than the existing system • In the real network without knowing packet loss rate

30. Thank You!