Improving Communication Quality with Reed Solomon Code in

Improving Communication Quality with Reed Solomon Code in Internet Voice Broadcasting System Shingo Kashima Kyushu University, Japan Asia-Pacific Advanced Network 2003 January 21 -24, 2003 Fukuoka, Japan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FEC Code Hamming code BCH code Fire code Reed Solomon code Error Usage semiconductor memory Ramdom storage of computers Error satellite broadcasting Burst Error magnetic memory storage of computers audio compact disk 17

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

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

Proposal of System [2 of 4] • The Stream of Sound Data HTTP/TCP RS code/UDP HTTP/TCP HT TP / RS RS encoding TCP→UDP TC P co d e /U DP RS decoding UDP→TCP HTTP/TCP HT TP / TC P RS decoding UDP→TCP 20

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

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) 22

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

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

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

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) more difficult to disconnect 26

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

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 28

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 29

Thank You! 30