Microsoft Word - km doc

Size: px

Start display at page:

Download "Microsoft Word - km doc"

솔미 만
5 years ago
Views:

1 工學碩士學位論文 인터넷에서고품질오디오스트리밍 서비스를위한복합적 QoS 보장기법 A Hybrid QoS Guarantee Scheme for High-Quality Internet Audio Streaming Services 指導敎授孫周永 2002 년 12 월 韓國海洋大學校大學院 컴퓨터工學科劉成日

2 工學碩士學位論文 인터넷에서고품질오디오스트리밍 서비스를위한복합적 QoS 보장기법 A Hybrid QoS Guarantee Scheme for High-Quality Internet Audio Streaming Services 指導敎授孫周永 2002 년 12 월 韓國海洋大學校大學院 컴퓨터工學科劉成日

3 목차제 1 장서론 연구배경 연구목적및제안기법...2 제 2 장관련연구 오디오스트리밍서비스개요 RTP ( REAL-TIME TRANSPORT PROTOCOL ) 멀티미디어데이터스트리밍서비스 QOS 보장기법...7 제 3 장오디오스트리밍서비스관련기초실험 인터넷데이터손실률 왕복시간 전송률에따른패킷간격...17 제 4 장복합적 QOS 보장기법 선택적재전송 클라이언트버퍼동적할당 전송률동적제어...23 제 5 장실험및결과 재전송소요시간 재전송완료시버퍼내의남은재생시간 분동안재생시수신측재생되지않은버퍼량변화 재전송시송신측패킷간격변화 재전송시수신측패킷간격변화...31 제 6 장결론및향후연구과제 참고문헌... 33

4 A Hybrid QoS Guarantee Scheme for High-Quality Internet Audio Streaming Services Seong-il Yoo Department of Computer Engineering Korea Maritime University, Busan, Korea Abstract This paper describes a hybrid QoS guarantee scheme for high quality audio streaming services on the Internet. One of the continuous multimedia data, digital audio, has the timing restrictions on transmission and playback over the packet switching networks. The continuous playback of the audio data requires the isochronous transmission of the audio data packet through the Internet. In order to retain the QoS at the ultimate destination (client) as the same as servers provide, the transmission protocols should consider the error conditions such as packet loss, and out of order delivery. Generally, the protocols supporting the transmission of continuous multimedia data do not recover the errors due to the packet loss, and out of order delivery. These are working good for the audio and video streaming services with the toll quality, but not for the high quality streaming services, such as the surround hi-fi sound/music playback. The hybrid QoS guarantee scheme includes the three mechanisms to overcome the problem. First, the selective retransmission is adopted to recover the packet loss with the minimal

5 overhead. Second, the adaptive buffering at client-side is designed to prevent from the starvation of audio data during the retransmission. Finally, the adaptive transmission rate at server-side is also used to maintain the isochronous transmission even after the retransmission due to packet loss. The experiments haven good results of the hybrid QoS guarantee scheme for the high quality audio streaming services on the Internet.

6 제 1 장서론 1.1 연구배경 인터넷을사용하는사용자의급격한증가와더불어인터넷을통한오디오데이터의전송도급격히증가하는추세이다. 단순한전화통화수준의음성통신에서인터넷을이용한온라인교향악콘서트음악감상, Hi-Fi 스테레오 FM 라디오방송의실시간중계, 주문형돌비 5.1 채널오디오서비스등고품질오디오서비스가요구되고있다. 오디오는특성상최종사용자단에서재생되는서비스품질 (QoS : Quality of Service) 이매우중요하다. 인간은비디오보다오디오에 더민감하기때문이다 [1]. 인터넷에서오디오스트리밍 서비스를하기위해서 는적게는초당 56Kbits에서 1.4Mbits의오디오데이터를지속적 (isochronous) 으로전송해야한다. 많은양의오디오데이터를지속적으로시간제약성에맞추어전달하는과정에서패킷손실, 패킷지연, 잘못된순서로도착하는현상이발생할수있으며, 이러한현상의정도에따라최종사용자단에서의 QoS가결정된다. 인터넷에서오디오데이터를전송하는데일반적으로사용되는 UDP 전송프로토콜은신뢰성있는데이터전달을보장하지않으며전송에러에대한정보도제공하지않는문제를가지고있다 [2]. 특히, 전송에러가운데패킷손실에의한수신측재생음질저하현상이 UDP 전송프로토콜을이용하는인터넷오디오스트리밍서비스에서주로발생한다. 이현상은일반적인음질 (tollquality) 서비스인경우에는사용자에게감지되어도크게문제가되지않으나고품질오디오서비스인경우에는현장감의저하로이어져전체서비스불만요인이된다. 이문제를해결하기위한연구들이진행되어왔다 [3,4,5]. 대표적인기법으로부가전송이나피드백제어기법들이제시되어있다 [3,4]. 이기법들의공통적인특징은패킷손실에대해수신측이주도적으로행하는것으로 1

7 부분적인에러복구방법이다. 부가전송은앞서전송된패킷의손실된데이터및오류복구정보를다음패킷에포함하여전송하며, 피드백제어는수신측의주기적인피드백정보에의해송신측의전송률및부호화방법을다르게하여전송하는기법이다. 1.2 연구목적및제안기법 고품질의오디오를결함없이그대로재생하기위해서는, 앞서제시된두가지기법으로는부족하다. 2.3절에자세히설명이되어있듯이부분적인에러복구를통해서는수신측에서완전하게데이터를수신하기가불가능하기때문이다. 본논문에서는 RTP/UDP를이용한고품질오디오스트리밍서비스에서클라이언트에서의재생품질을서버에서제공하는오디오데이터고유의품질과동일한품질로보장하기위해복합적 QoS 보장기법을제안한다. 복합적기법에는크게세가지기법이포함되어상호보완적으로작동함으로써최종적인재생품질의보장을담보한다. 첫째, 전송중에손실된패킷을 RTCP 피드백을이용하여선택적으로재전송하고, 둘째, 재전송에의해발생될수있는오디오데이터의전송등시성 (isochronous transmission) 결손을보장하기위해수신측버퍼를동적으로할당하여재전송에필요한시간을보장받는다. 셋째, 서버측에서전송률제어를함께시행하여이러한재전송에의해이어지는다음오디오데이터의전송률저하현상을막는다. 세가지기법에의해작동되는제안기법이실제인터넷상에서운용되는데결정되어야하는파라미터 ( 전송률, 에러에의한재전송률, 클라이언트에서유지해야하는버퍼크기 ) 를얻기위해실제인터넷에서많은실험을통해인터넷의전송특성을측정하여도출하였다. 2

8 실험은재전송률과깊은관련이있는인터넷에서의 RTP/UDP 데이터전송손실률과, 송수신함에있어걸리는왕복시간 (RTT : Round Trip Time) 을측정하였다. 그결과, 인터넷전송손실률은시간대별로가변적이나약 5% 내외로밝혀졌고, 전송왕복시간도 2홉을거치는실험에서약 5.3ms로밝혀졌다. 이를기반으로제안된복합적 QoS 보장기법에서규정해야하는전송률과재전송에따른버퍼량, 전송률변화율을도출하였다. 이를기반으로설계된오디오스트리밍서비스서버, 클라이언트시스템을실제인터넷에서운용하고실험한결과, 기존방식에비해적은재전송률과버퍼량으로고품질오디오스트리밍서비스의품질이확실하게보장됨을확인하였다. 본논문의구성은다음과같다. 2장에서는인터넷에서의오디오재생스트리밍서비스에서 QoS를보장하기위한기존의연구내용을살피고, 3장은실제인터넷의전송특성을파악하기위한기초실험결과를설명하고, 4장에서는본논문에서제안하는복합적 QoS 보장기법인동적버퍼할당기법, 재전송요청기법, 그리고전송률동적제어기법을자세하게설명한다. 5장에서는제안된기법을채택한서버와클라이언트시스템을구현하여실제인터넷에서적용한실험결과를보이며, 마지막으로 6장에서향후연구방향과결론을내린다. 3

9 제 2 장관련연구 2.1 오디오스트리밍서비스개요 인터넷상에서전송되는데이터는주로이진 (binary) 파일이나텍스트형태의데이터이며수신측에서완전히수신한후보여주는다운로드방식이주를이루고있다. TCP/IP 기반의데이터전송에서는프로토콜 (protocol) 자체의에러처리방법에따라에러없는데이터의수신과재생이가능하다. 하지만 TCP 전송프로토콜은다음과같은특성에의해멀티미디어데이터의스트리밍전송에적합하지못하다 [2]. 첫째, 손실없는데이터수신을위해과도한 ACK전송과재전송으로인해스트리밍서비스의시간제약성을만족하지못한다. 둘째, TCP/IP와같은공격적프로토콜은네트워크대역폭에여유가있을경우 slowstart와같은기법에의해대역폭의대부분을차지하게된다. 이러한경우수신측의과도한버퍼할당과재생되는데이터의실시간성을만족시키지못한다 [6]. 오디오스트리밍서비스는전체데이터를다운로드후보여주는방식과는다르게부분적인데이터라도수신과동시에재생이된다. 송신측의전송이되는동안수신측에서는재생이되며송신측의전송완료와동시에수신측의재생도완료된다. 다운로드완료후보여주는방식은전송하고자하는데이터가파일과같이저장된내용이지만오디오스트리밍서비스는인터넷방송, 스포츠중계와같이실시간으로발생하는데이터를전송및재생할수있으며최근대두되고있는멀티미디어데이터의저작권에관련된문제도해결할수있는장점이있다. 인터넷스트리밍서비스를가능하게하는기술로는다음세가지를들수있다. 첫째, 서버측스트리밍기술이다. 실시간으로발생하는데이터를수집, 압축하여저장과동시에인터넷을통해전송한다. 비디오캠이나오디오입력을통해수집되는데이터를스트림이가능한형태로변환하여스트림서버에서네트워크를통해전송한다 [6]. 둘째, IETF(Internet Engineering Task Force) 에서표준화한 RTP/RTCP 등일 4

10 련의멀티미디어데이터전송프로토콜이다 ( 그림 1). RSVP RTP RTCP RTSP HTTP UDP TCP IP Ethernet ATM 그림 1. 인터넷멀티미디어전송프로토콜스택 RSVP(Resource Reservation Protocol) 는비디오와다른고대역폭의멀티캐스트메시지전송을위해인터넷상의채널들이나경로들을예약할수있도록해주는프로토콜이다. RTP(Real-time Transport Protocol) 는오디오와비디오와같은실시간데이터를전송하기위한인터넷프로토콜로서 UDP를기반으로동작한다. 자세한내용은 2.2절에기술되어있다. RTCP(Real-time Transport Control Protocol) 는 RTP의 QoS를유지하기위해 RTP와함께쓰이는시그널링제어프로토콜이다. RTP는데이터전송에만관계하지만, RTCP는데이터전송을감시하고, 세션관련정보를전송하는데관여한다. RTSP(Real-Time Streaming Protocol) 는월드와이드웹상에서멀티미디어스트리밍데이터를제어하는방법에대한표준안이다. HTTP(Hypertext Transfer Protocol) 는웹상에서파일 ( 텍스트, 그래픽이미지, 사운드, 비디오그리고기타멀티미디어파일 ) 을주고받는데필요한프로토콜로서 TCP/IP와관련된하나의응용프로토콜이다. UDP(User Datagram Protocol) 는 IP를사용하는네트워크내에서컴퓨터들간에메시지들이교환될때제한된서비스만을제공하는통신프로토콜이다. 에러없는데이터전송을보장하지는않지만전송지연면에서우수한특성을가지고있기때문에시간제약성을가지는멀티미디어데이터전송에적합하다. TCP(Transmission Control Protocol) 는인터넷상의컴퓨터들사이에서 5

11 데이터를메시지의형태로보내기위해 IP와함께사용되는프로토콜이다. 앞서설명한이유로멀티미디어데이터전송에는부적절한면을가지고있다. IP(Internet Protocol) 는인터넷상의한컴퓨터에서다른컴퓨터로데이터를보내는데필요한경로설정프로토콜이다. 비연결형위주로동작하기때문에망내의트래픽부하균등, 결함내성이매우강하다. 오디오스트림전송은주로 RTP/UDP를이용하여전송하게되는데동기화및대역폭측정등과같은실시간스트림에서지원해야하는부가기능을지원하지못하는문제점이존재한다. 이러한문제점을해결하기위해 XTP(eXpress Transport Protocol), HSTP(High Speed Transport Protocol), VMTP(Versatile Message Transaction Protocol) 등의많은프로토콜들이제안되었다 [7]. 셋째, 클라이언트측재생기술이다. 전송된멀티미디어데이터의압축해제및재생, 그리고안정적인재생을위한버퍼제어의기능이내포되어있다. 인터넷상의대표적인프로그램으로넷스케이프사의 LiveMedia 기술, 마이크로소프트사의 WMT(Windows Media Technology) 에기반한 NetMeeting, Windows Media Player, Real Network 사의 Helix 기술에바탕을둔 RealPlayer 등을들수있다. 2.2 RTP ( Real-time Transport Protocol ) V=2 P X CC M PT Sequence Number Timestamp S ynchronization S ource(s S R C ) Indetifiers C ontributing Source(C SRC ) Identifiers Defined by Profile Length of H eader Extension H eader Extension Padding Octets Num ber of Paddings 그림 2. RTP Header 구조 6

12 RTP 는유니캐스트를비롯하여멀티캐스트네트워크상에서오디오, 비디오데이터와같은연속미디어데이터 (Continuous Media Data) 를실시간으로처리 (retrieval) 하는응용에맞게데이터전송기능을수행하는수송계층프로토콜이다 [7]. 프로토콜헤더구조에서 V 는버전, P 는 Padding, X 는 Extension, CC 는 CSRC 카운터, M 은 Marker, PT 는 Payload Type 을의미한다. RTP 는실시간데이터의단말-대-단말네트워크전송기능을제공하지만전송품질을보장하지는않는다. 전송품질감시, 매체식별, 및제어기능을담당하는제어프로토콜인 RTCP 와세트를이루며전송및네트워크계층에독립적으로동작한다. 응용의필요에따라헤더를추가하거나변경할수있는일종의맞춤형프로토콜이다 [8]. 이를위해 RTP Payload 의종류와형식을명시하는 Profile 문서와 RTP Payload 의전송방법을명시하는 Payload Format 문서를필요로한다. RTP 헤더의 Marker 와 PT 필드는응용에서변경할수있고, RTP 헤더의 X 비트를이용해서응용은필요한확장헤더를추가할수있다.RTCP는데이터패킷과같은방법으로제어패킷을주기적으로전송하는프로토콜이며 [9] 데이터전송품질에대한피드백 (SR, RR) 을제공한다. RTP 전송자의식별을위해지속적인식별자 (SDES-CNAME) 를제공하며최소한의 RTP 세션제어정보 (SDES, BYE, APP) 를제공한다. RTCP 메시지의종류로는 SR(Sender Report), RR(Receiver Report), SDES(Source Description), BYE(End of Session), APP(Application-defined) 등이있다 [10]. UDP 는비연결형서비스를어플리케이션에게제공하는프로토콜로서 RTP 의기반이되는프로토콜이다. UDP는 TCP 와는달리, 메시지를패킷으로나누고, 반대편에서재조립하는등의서비스는제공하지않으며, 도착하는데이터패킷들의순서를제공하지않는다. UDP 를사용하는멀티미디어데이터스트리밍서비스에서는전체메시지가올바른순서로도착했는지에대해확인할수있는메커니즘이있어야한다는것을의미한다. 이를위해 RTP 가 UDP 위에서활용되는것이다. 2.3 멀티미디어데이터스트리밍서비스 QoS 보장기법 7

13 멀티미디어데이터를전송하는프로토콜은수신자에게더많은정보를전달하기위해 RTP와같은응용계층의프로토콜을사용한다. 이러한프로토콜울사용하는경우수신자는 2 ~ 5% 의패킷손실을경험한다 [11]. 이경우패킷손실로인한수신측의재생품질저하현상이발생하며이러한품질저하현상을극복하기위해여러가지에러복구방법이제안되었다 부가전송 ( Redundant Transmission ) 멀티미디어데이터전송시손실된패킷에따른복구문제를수신측에서처리할수있도록부가정보 (redundant information) 를후속패킷에추가하여보내는방식이다 [3]. 추가지연없이패킷손실에대한복구정보를제공하여전방위에러수정 (forward error correction) 이가능한장점이있는반면보낸패킷에대한부가정보를다음패킷에추가함에따라정보전송에따른전송량증가가요구되는단점을가진다 [13]. 패킷전송 서버 서버 < 비부가전송 > - No redundant 패킷전송 부가정보 < 1-order 부가전송 > - Lower Packet Loss 클라이언트 클라이언트 서버 패킷전송 부가정보 < 2-order 부가전송 > - Higher Packet Loss 클라이언트 그림 3. 부가전송부가전송방식은패킷손실을고려하여수신측에서복구할수있도록송신측에서패킷의중복성을허용하는방식으로이를위한 RTP 패킷은원본데이터에해당하는 PEB(Primary Encoded Block) 과패킷손실에대비한부가정보에 8

14 해당하는 REB(Redundant Encoded Block) 으로구성된다 [3]. REB는패킷손실량이낮은네트워크환경에서는 REB 크기만큼의대역폭을낭비하게된다. 이경우수신측의 RTCP 피드백정보를이용하여부가전송메커니즘을동적으로적용할수있다. 패킷손실이없거나매우적은경우비부가전송에해당하는 PEB만을전송함으로써네트워크대역폭을최소화할수있으며부가전송방식을적용할경우 REB를몇번째후속패킷에부가할것인가하는부가전송방식의순서문제로, 이는패킷손실의연속성에의존한다. 피드백된패킷손실률이임계값보다큰경우부가전송방식알고리즘을적용하여손실된패킷을수신측에서복구할수있도록한다 [3] 재전송 ( Retransmission ) 재전송방법은일반적으로오디오데이터의특성상스트림전송에사용되지않는방법이다. 오디오스트림데이터는송신측과수신사이의지연시간에민감하기때문에재전송방법을사용할경우재전송된데이터가제한된시간이내에수신측에도착하지않을수있기때문이다. 하지만재전송방법이모든경우에사용될수없는것은아니다. 종단간의지연시간이짧고패킷손실률이적은경우사용이가능하며재전송에의한손실패킷복구방법은가장확실한복구방법이다 [11]. 그러나재전송요청으로인한오버헤더가증가하는단점이있다 삽입기반복구 ( Insertion-Based Repair ) 삽입기반복구방법은손실된패킷을단순한데이터로대체하는방법이다. 수신측에서수신도중손실된패킷부분을무음이나특정노이즈 (noise), 앞서전달된패킷으로대처하여연속적인재생이가능하다 [11]. 이방법의경우부가정보전송이나재전송으로인한오버헤더는전혀발생하지않으나앞서설명된부가정보전송방법이나재전송방법과는달리손실된패킷에대한복구가전혀이루어질수없기때문에재생품질이현저히저하되는단점이있다. 9

15 2.3.4 흐름제어 송신측과수신측간의사용가능한대역폭상태에대한수신측의피드백정보전달빈도수를조절함으로써효율적으로대역폭을이용하는방법이다 [9]. 대역폭의부하가적을경우피드백빈도수를적게하고혼잡상태일때는빈도수를많게하여통신망의현재상태를송신측이최대한빨리파악하도록하여전송률을조절한다. 멀티미디어데이터의전송에사용되는 UDP 전송프로토콜이 TCP와같은프로토콜과함께사용될경우수신측의피드백정보없이고정적인전송률로전송한다면 TCP의슬라이딩윈도우프로토콜 (sliding-windowprotocol) 에의해대역폭이점령당하게되어지속적인스트림전송이어려워진다. 네트워크가혼잡상태일때는수신측의피드백정보빈도수를조절함으로써송신측과수신측간의네트워크상태를송신측에즉시피드백하여송신측에서는현재의대역폭범위에맞는전송을통해전송되는데이터의손실을줄인다. 이러한흐름제어기법은송수신측간의피드백정보를통한대역폭의효율적사용이라는장점이있으나, 고품질의멀티미디어데이터전송시발생하는패킷손실에대해복구할수없는단점이있다. 이것은고품질멀티미디어데이터일수록고속의전송률을요구하며흐름제어기법을통해서는패킷손실에대한보장을하기어렵기때문이다 [5,12] 주기적피드백제어 수신측의주기적피드백정보에의해송신측에서부호화방법과전송률을제어하는방법이다 [4]. 수신측에서파악된전송상태를송신측에피드백하여전송되는데이터량을조절하기위해다음과같은사항을고려해야한다 [14]. 첫째, 전송되는데이터의실시간성을고려하여시기적절한피드백을제공하여야한다. 둘째, 피드백정보의트래픽으로인해수신정보의품질이영향을받지않아야한다. 셋째, 지연시간에민감한네트워크의혼잡상황에대해빠른피드 10

16 백을제공하여야한다. 적절한피드백정보를통해전송제어효과를얻을수있으나주기적인피드백정보만으로는수신측의현재상태를즉각적으로피드백할수없으며통신망혼잡으로인해피드백정보가유실되는경우피드백정보전송이다음피드백정보의전송까지지연되므로수신측버퍼고갈이나오버플로우현상이나타날수있다. 11

17 제 3 장오디오스트리밍서비스관련기초실험 본논문에서제안하는복합적 QoS 보장기법이현실적으로적용가능한지에대한기초실험을실시하였다. 재전송에의한 QoS 보장기법과클라이언트측의동반되는동적버퍼링기법그리고서버측의동적인전송률제어기법이현실적으로적용가능성이있는지여부를판단하기위해인터넷전송특성에대한사전조사를실시하였다. 3.1 인터넷데이터손실률 인터넷상의패킷손실률은재전송빈도수와비례하므로손실률을파악함으로써재전송에따른추가적인부하정도를예측할수있다. 이를위해현재인터넷상의 RTP 데이터가손실되는형태와 RTCP 피드백을통한재전송하는데소요되는시간의측정이선행되어야한다. RTP 데이터가손실되는형태를조사하기위한실험방법은 RTP 데이터를전송하는서버프로그램과수신하는클라이언트프로그램을제작하여서버프로그램에서 RTP 데이터패킷을전송하고클라이언트프로그램에서패킷을수신할때패킷헤더번호에의한손실된패킷을조사하였다. Server Hub Gateway C am pus N etwo rk Gateway Hub Client 그림 4. 기초실험환경 실험환경은 RTP 패킷을전송하는서버와패킷을수신하는클라이언트를각 각의허브에접속하여인터넷을경유하도록하였다. 서버와클라이언트시스템 12

18 은 PC 에서동작한다. 운영체제는 Windows 2000 이고, 개발도구는 Visual C++ 상에서 Win32 SDK 를이용하여 C 언어로작성되었다. 프로그램시작 프로그램시작 초기세션연결 초기세션연결및초기버퍼크기설정 전송시작 수신시작 전송률조절 전송 수신 아니오 예 전송률조절요청인가 아니오 전송 아니오 재전송인가 아니오 전송완료 예 재전송패킷확인 재전송 예 재전송요청 예 재전송요청인가 아니오 버퍼링 전송률조절요청인가 예 전송률조절요청 예 재전송완료 재생 전송끝 아니오 재생끝 < 서버프로그램흐름도 > < 클라이언트프로그램흐름도 > 그림 5. 서버 / 클라이언트프로그램흐름도 서버프로그램은초기세션연결후전송을시작하며클라이언트에서의재전송요청과전송률조절요청을받아들인다. 전송은메인스레드 (main thread) 에서담당하며재전송요청과전송률조절요청은서브스레드 (sub thread) 에서받아들여처리한다. 클라이언트프로그램은초기세션연결시동적인버퍼크기를결정하며패킷수신이후와버퍼링도중에손실된패킷의재전송요청과전송률조절을요청한다. 서버와클라이언트는서로다른서브넷에속하는 IP 주소를가지고있으며각서브넷의게이트웨이를경유하여패킷을전송하였다. 서버측에서전송된 RTP 패킷은서버가속해있는네트워크의게이트웨이를경유하여클라이언트가속해있는네트워크의게이트웨이에도착하여클라이언트로전달된다. RTP 13

19 패킷은총 2 개의게이트웨이를경유하여전송되었다. 실험환경에서 RTP 데이 터의시간대별손실률실험을실시하였다 손실률 ( % ) :00 11:00 12:00 13:00 14:00 15:00 16:00 시간대 그림 6. 시간대별데이터손실률 서버에서 128 bytes의패킷크기를가지는 100 개의 RTP 패킷을 256 Kbps 속도로전송한후클라이언트에도착한패킷개수를측정하였다. 같은방법으로각각 200개부터 1000개의 RTP 패킷을전송한후클라이언트에도착한패킷개수를측정하였다. 그림 6은캠퍼스내의두개의게이트웨이 (2 hop) 를경유하는그림 4의기초실험환경에서 256 Kbps의속도로 3 일에걸쳐오전 10 시부터오후 4시까지의 RTP 패킷의손실률평균을나타내었다. 실험결과를보면오전 11시부터패킷손실이급격히증가하여오후 4시이후에점차손실률이줄어드는것을알수있다. 이것은인터넷상의패킷들이집중되는시간대에 RTP 데이터의손실도함께증가함을보여주는것이다. 최대손실은오후 1시에 700개의패킷을연속해서전송하는경우, 4.48% 로나타내 14

20 고, 오전 11시에 200개의패킷을연속해서전송하는경우에 0.1% 로나타났다. 실험한인터넷에서평균손실률은 4.2% 미만이다. 이값은손실된패킷을재전송하는경우발생되는트래픽의증가량으로볼수있다. 전체 RTP 패킷의약 5% 에대한재전송으로완전한데이터전송이가능하게되므로서버에서제공되는오디오품질이그대로클라이언트에서재생될수있다. 3.2 왕복시간 다음으로실험된내용은재전송에소요되는시간이오디오데이터의전송등시성을만족시킬수있는지에대한여부에관한것이다. 오디오데이터의특성상재전송에기반하여완전한데이터를수신한경우라도재생되어야할시점이후에클라이언트에도착하였다면의미가없다. 따라서 RTCP 피드백을통한손실된패킷의재전송에소요되는시간을조사해볼필요가있다. 실험방법은클라이언트의 RTP 패킷재전송요청시점에서부터요청된패킷이서버에서전송되어클라이언트에도착하는시점까지의소요시간, 즉왕복시간 (RTT : Round Trip Time) 을조사하였다.( 그림 7) 서버 클라이언트 RTP 패킷요청 왕복시간 RTP 패킷전송 그림 7. 측정된왕복시간 15

21 6 소요시간 ( ms ) :00~02:00 03:00~04:00 05:00~06:00 07:00~08:00 09:00~10:00 11:00~12:00 13:00~14:00 시간대 15:00~16:00 17:00~18:00 19:00~20:00 21:00~22:00 23:00~24:00 그림 8. 왕복시간 그림 8 은그림 4의실험환경에서 24 시간에걸쳐측정된결과이다. 5분간격으로 128 bytes 크기의패킷한개를클라이언트에서서버로전송하는시점부터서버에서이를다시클라이언트로전송하여전송이완료되는시점까지의시간을측정하여평균으로나타내었다. 측정된왕복시간은오후 1시부터오후 2시까지최대 5.3 ms, 오전 9시부터오전 10시사이에최소 4.4 ms로나타났다. 또한왕복시간은인터넷사용량이증가하는시간대인오전 11시에서약간증가하는것을볼수있으며, 일정시간동안 4 ~ 6 ms를소요하는것을알수있다. 이실험에의해얻어진결과에의하면클라이언트에서유지해야하는버퍼크기가전송률이 128Kbps인경우는 98 bytes, 256Kbps인경우는 49 bytes 로유지되면된다. 이를통해매우작은버퍼만으로선택적재전송에의해패킷손실에대처할수있음을알수있다. 현재측정된왕복시간은, 서버프로그램이 RTP 데이터패킷을전송하지않고있고, 재전송요청에따른처리를고려하지않은상태에서측정된것으로패킷의재전송에따른서버프로그램에서의처리시간 (processing time) 이포함되 16

22 어있지않은경우이다. 실제적인 RTP 데이터패킷을전송하는동안재전송에 대한소요시간은 5 장실험및결과에제시되어있다. 3.3 전송률에따른패킷간격 한번에전송되는패킷의크기에따라서버에서전송하는데이터에대한패킷과패킷간의간격이달라질수있다. 오디오데이터의전송률을일정하게유지하기위해서는패킷크기가커질수록패킷간격은넓어지며패킷크기가작아질수록패킷간격은좁아져야한다. 표 1은 2분간재생되는다양한재생률을가지는오디오데이터를전송하기위해패킷크기를 128 bytes로고정할경우각재생률에따른패킷간격을나타낸다. 표 1. 전송률에따른패킷간격 전송률샘플링률패킷크기패킷간격채널 ( Kbps ) ( Hz ) ( Bytes ) ( ms ) Stereo Stereo Stereo Stereo Stereo Stereo Stereo Mono 그림 7 의실험결과와표 1 의결과로볼때 128 Kbps 의 stereo 수준의오디오 17

23 데이터는단독으로손실된패킷에대한재전송인경우에는수신측에서의버퍼링없이도시간제약성을만족시키는것을볼수있다 [4]. 그러나그보다나은품질의오디오데이터는단독손실패킷에대해서도재생 QoS에영향을받으며더나쁜환경에서는품질열화가충분히예견된다. 이를극복하기위하여본논문에서제시하는복합적 QoS 보장기법이적용된다. 18

24 제 4 장복합적 QoS 보장기법 복합적 QoS 보장기법은세가지기법으로구성된다. 첫째, 손실된패킷에대한선택적재전송, 둘째, 클라이언트버퍼의동적할당, 셋째, 서버에서의전송률동적제어등이다. 컴퓨터통신망에서에러가난패킷을재전송하는대표적기법으로정지대기 (stop-and-wait), 후진-N(Go-Back-N), 그리고선택적재전송 (Selective Repeat) 등이있다. 정지대기기법은각각의전송된패킷에대한응답을받음으로네트워크대역폭낭비가극심하며 [15], 후진-N 기법은손실발생시손실되지않은패킷도전송함으로써대역폭의낭비및실시간성을만족하기에부적절한점이있다 [15]. 선택적재전송방법은인터넷에서신뢰성있는전송을보장하는 TCP에서사용하는재전송방법이다 [15]. 3.2절의기초실험결과에서재전송에소요되는왕복시간은극히짧은시간 ( 약 5ms) 임을확인할수있으며, 손실패킷재전송에요구되는비용면에서선택적재전송기법이가장적은것으로나타나있다 [15,16]. 따라서본논문에서는 TCP에서의흐름제어및재전송방법에사용되는선택적재전송기법을 RTP/UDP 기반오디오데이터전송의재전송기법으로채택한다. 클라이언트버퍼동적할당기법은송신측과수신측의초기세션 (session) 연결시왕복시간을측정하여왕복시간동안재생할수있는크기만큼의버퍼공간을할당하는기법이다. 이를통해송수신측간의네트워크상태를고려한수신측버퍼크기할당을통해버퍼공간의낭비를최소화할수있을뿐만아니라손실된패킷의재전송에소요되는시간을보장받을수있다. 서버에서의전송률동적제어기법은송신측에서일정한패킷간격으로전송한 RTP/UDP 패킷이수신측에일정한간격으로도착하지않는경우에발생할수있는수신측버퍼고갈 (starvation) 이나오버플로우 (overflow) 현상을막기위 19

25 한것이다. 수신측버퍼의상태와동적인왕복시간을지속적으로모니터링하여 측정하고그상황에따라송신측에현재전송되고있는패킷들의간격조절요 청을통해전송률을동적으로제어한다. 4.1 선택적재전송 클라이언트는서버로부터수신된패킷에대해 RTP 헤더의순서번호를확인한다. 만약연속해서수신된패킷의순서번호가연속적이지않은경우, 연속적이지않은패킷크기만큼버퍼공간을채우지않고버퍼링을진행한다. UDP를기반으로하는프로토콜의경우패킷도착의순서가보장되지않음으로재전송요청이전에패킷이도착할수도있기때문이다. 수신된 RTP 패킷 패킷패킷비어있는버퍼패킷패킷.. t. 패킷패킷패킷 < 클라이언트버퍼 > < 오디오재생장치 > 그림 9. 재전송요청시점 재전송요청시점은비어있는버퍼공간직전까지재생하는데소요되는시 간 (t) 이왕복시간에해당하는시간이되었을시점 (t RTT) 이다. 재전송요청 20

26 시점이전에도착하는패킷은비어있는공간에채워진다. 재전송요청은 RTCP 의 RR(Receiver Report) 메시지를통해이루어지고재전송성공시버퍼내의비어있는공간에채워진다. 그림 10은선택적재전송에의해나타날수있는클라이언트의버퍼상태를모식화한것이다. 패킷전송시간 ( t ) 재전송송신측네트워크인터페이스 손실 수신측네트워크인터페이스 재전송요청 초기지연시간 D 수신측버퍼 재생지연시간 버퍼링된패킷재생 그림 10. 재전송발생시수신측버퍼상태변화 클라이언트에서는초기버퍼링시간동안지연이발생하며이지연시간은서버와클라이언트사이의왕복시간동안재생되는데이터의양을기초로한다. 초기지연시간이후버퍼링된패킷들을재생하기시작한다. 그림 9에서서버에서전송하는 RTP 패킷중 8번패킷이손실이발생한경우클라이언트에서는 8번패킷크기에해당하는버퍼공간만큼을채우지않고다음패킷의버퍼링을진행한다. 9번패킷이후에패킷의손실이확인되었고 8번패킷까지의재생시간이왕복시간에해당하는시간이되었을경우클라이언트에서는재전송을요청한다. 서버에서는 8번패킷의재전송요청이발생하였을때 10번과 11번패킷의정상적인패킷간격사이에손실된 8번패킷을전송한다. 클라이언트에서는비어 21

27 있는버퍼공간에 8 번패킷을할당하게되므로모든 RTP 패킷이마감시간이 전에클라이언트에수신하게되어완전한재생품질을유지한다. 4.2 클라이언트버퍼동적할당 에러가없는네트워크환경 송신측에서전송된패킷이수신측에손실없이도착할수있는이상적인네트워크환경일경우에는수신측버퍼소모율, 즉재생률을 r 이라두고, 송신측전송률을 s 라고할때송신측전송률과수신측소모율은식 (1) 과같이되어야한다. s = r ( 1 ) 그러나실제인터넷상에서전송되는 RTP/UDP 기반의데이터는송신측에서일정간격으로패킷을전송하여도각패킷의전송지연시간이각각다를수있기때문에수신측에도착하는패킷의간격은가변적이다. 이로인해전송등시성이유지되지못하는현상이발생할수있다. 수신측에서는가변적인패킷도착시간을극복하기위해버퍼를가져야하며그버퍼크기는송수신측간의네트워크상태를고려하여동적으로조절되어야한다 클라이언트초기버퍼크기 송신측과수신측이처음세션을연결할때그당시의왕복시간을고려하여클라이언트초기버퍼크기를결정한다. 클라이언트초기버퍼크기는송신측과수신측간왕복시간동안재생되는오디오데이터의양과동일한값을가지게된다. 단독패킷에러가발생할상황에대비하여반드시만족되어야하는최소초기버퍼크기 B 는식 (2) 와같다. B = 재생률 왕복시간 (bit ) ( 2 ) 22

28 B bits의데이터를수신하는도중패킷이손실될수있으며이에대한재전송에소요되는시간을감안할때, 수신측의버퍼는최소버퍼크기보다커야한다. 한개의패킷이전송되는중에에러가날확률을 P 라할때 B 를채우기위해서버가전송하는전송량 T 는식 (3) 과같다 [15]. B T = ( bit) ( 3 ) 1 P 서버에서한패킷이에러가난경우, 전송량의증가가초래됨으로써재전송후에는전송률이상향조절되어야클라이언트의버퍼를적어도초기버퍼크기이상으로유지할수있다. 이에따라클라이언트의버퍼량이일시적으로증가하는현상이발생할수있으나, 곧이은전송률하향조절로버퍼량의증가현상을없앨수있다. 4.3 전송률동적제어 전송률조정요청시점 전송률동적제어기법은송신측에서전송하는패킷간격을수신측의요청에의해조절하는기법이다. 수신측에서송신측에대한전송조정요청시점은수신측의버퍼모니터링과동적인왕복시간측정을통해가능하다 [17,18]. 수신측에도착한패킷까지의버퍼내데이터재생시간이왕복시간보다짧은경우에전송률증가요청을한다. 반면수신측버퍼내데이터재생시간이왕복시간보다긴경우에는전송률감소요청을한다. 전송률의증가또는감소는송신측에서전송하는패킷사이의간격을수신측에서요청한 ms 단위의패킷간격조정요청을통해이루어진다. 송신측에서현재전송중인패킷의간격을 1ms 조절할경우단위시간당수신측에도착하는패킷의수는달라지며, 수신측버퍼량은점진적으로증가또는감소한다. 앞서제시한표 1 경우에대한패킷수변화와클라이언트버퍼량변화예측표를표 2에서보인다. 23

29 표 2. 1 ms 간격조절에의한패킷수와버퍼량변화 전송률 ( Kbps ) 패킷크기 패킷간격 1ms 좁힘 / 넓힘 ( Bytes ) 1초간증가 / 감소패킷수 1초간증가 / 감소버퍼량 bytes bytes bytes bytes bytes bytes bytes 송신측에서전송하는패킷간격을 1ms 조절할경우 320Kbps에서는 1초동안 13213bytes의버퍼량변화를보이며전송률이가장낮은 20Kbps에서는 52bytes의버퍼량변화를보였다. 전송률이높을수록단위시간당변화하는버퍼량이커지며전송률이낮을수록단위시간당변화하는버퍼량이작아진다 송신측패킷간격변화 수신측동적인전송률조절요청이외에재전송요청이발생한경우송신측은기존의전송하는패킷과재전송이요청된패킷을전송하게된다. 재전송이요청된패킷은기존의패킷사이간격이내의시간에전송이이루어지며순간적으로송신측에서의재전송요청시패킷간격은기존패킷간격에비해절반이하의간격으로좁아진다 ( 그림 11). 24

30 패킷전송 패킷 패킷 패킷패킷패킷패킷 서버 정상패킷간격 재전송시패킷간격 재전송요청된패킷 클라이언트 그림 11. 재전송시패킷간격 이는수신측에서는비어있는버퍼를채우는것일뿐, 단위시간당전송에서변화가아니므로수신측버퍼는일정크기를유지할수있다. 수신측은재전송이완료되었을경우버퍼내의비어있는공간을재전송된패킷으로대체한다. 이것은재전송패킷의재생마감시간이전에모두완료되어야한다. 25

31 제 5 장실험및결과 동적인버퍼를동적으로할당할수있는클라이언트와선택적재전송과동적으로전송률제어가가능한서버프로그램을설계, 구현하여 RTP 데이터트래픽을모니터링하였다. 서버와클라이언트프로그램은 Microsoft Windows 2000 운영체제상의 Win32 SDK를사용하여 C언어로제작되었으며, 그림 4의기초실험환경에서서버에서클라이언트로 RTP 데이터전송중에재전송소요시간측정과클라이언트버퍼의고갈현상을확인하기위해재전송완료시버퍼내의남은데이터량측정과클라이언트버퍼량변화를확인하기위해 2분간서버에서클라이언트로 RTP 데이터전송시클라이언트의버퍼량을측정하였다. 그리고재전송요청시패킷간격변화를확인하기위해같은시점에서버에서전송되는패킷간격과클라이언트에수신되는패킷간격을측정하였다. 5.1 재전송소요시간 재전송이요청된패킷이버퍼의고갈이전에도착하는지여부와전송률제어를통해버퍼가적정크기로유지되는지여부를확인하기위해오전 10시부터오후 4시사이에 30분간격으로서버에서 128 bytes 크기의 RTP 패킷 100개를 128Kbps 속도로클라이언트로전송하는실험을하였다. 전송도중패킷손실이발생할수있으며재전송소요시간은클라이언트에서재전송요청패킷을전송하는시점부터서버로부터재전송된패킷이클라이언트에전송완료되는시점까지이다. 클라이언트에서손실된패킷확인후재전송요청에소요되는시간은포함되지않은시간이며실제인터넷환경에서는클라이언트에서재전송요청에소요되는처리시간을합한만큼의재전송소요시간이필요하다. 그림 13에손실된패킷에대한재전송소요시간을나타내었다. 26

32 누적패킷개수 시각 ( 분 ) 그림 12. 패킷전송누적패턴 시간 ( ms ) :00 10:30 11:00 11:30 12:00 12:30 13:00 13:30 시간대 14:00 14:30 15:00 15:30 16:00 그림 13. 재전송소요시간 재전송에소요되는시간은클라이언트가서버로재전송요청패킷이전달되는시간과요청된패킷을서버에서클라이언트로전송하는데소요되는시간의합이다. 실험결과재전송소요시간은최소 15.1 ms에서최대 19.8 ms로나타났다. 그림 8에서측정된왕복시간 4ms ~ 6ms 보다는약 11.1ms ~ 13.8ms 시간이더소요되는시간이다. 이는서버에서클라이언트로부터재전송요청된패킷을확인후재전송하기위해소요되는처리시간이더해지기때문이다. 서버에서는재전송요청된패킷을재전송하는데약 12ms의일정한시간을소요하지만클라이언트의재전송요청에소요되는처리시간과동적인왕복시간을기준으로한재전송요청시점으로인해클라이언트의버퍼크기는재전송에소요되는시간동안재생되는데이터양보다커질수있다. 다음실험에서실제인 27

33 터넷환경에서측정된전체재전송시간에기반한재전송완료시클라이언트버퍼내의남은재생시간을나타내었다. 5.2 재전송완료시버퍼내의남은재생시간 그림 14는재전송완료시클라이언트버퍼내의재전송이요청된패킷직전까지의데이터양을데이터재생률을근거로시간값으로표현한것이다. 시간 ( ms ) :00 10:30 11:00 11:30 12:00 12:30 13:00 13:30 14:00 14:30 15:00 15:30 16:00 시간대 그림 14. 재전송완료시버퍼내의남은재생시간 송신측과수신측의왕복시간에기준한동적인버퍼할당은데이터전송시네트워크상황을고려한버퍼크기이며전송률동적제어를통해그림 14 의결과와같이버퍼내의데이터의양을일정하게유지할수있다. 재전송완료시재전송요청된패킷직전까지의버퍼내의데이터재생여유시간이 110ms ~ 130ms 임으로서재전송요청된패킷이재생시점이전에도착함을알수있다. 128 Kbps 이상의전송률에대하여수신측버퍼의재생되지않은데이터양을확인하기위해수신측버퍼내의남은재생시간이가장적은시간대인오후 12 시부터오후 2시사이에각각 128Kbps, 256Kbps 그리고 320Kbps 전송률로 2 분간재생할수있는데이터를전송하였을때수신측의재생되지않은버퍼량의변화를실험하였다. 28

34 5.3 2 분동안재생시수신측재생되지않은버퍼량변화 재생시간이 120초인오디오데이터를스트리밍방식으로전송, 재생할때클라이언트버퍼크기변화를측정하였다. 이를통해오디오가재생되는동안항상 RTT 시간보다상회하는버퍼량이클라이언트에유지되는것을확인할수있고재생품질의열화현상이전혀발생하지않음을알수있는것이다. 실험은재생률이각각 128Kbps, 256Kbps 그리고 320Kbps인고품질오디오데이터에대해각각실행되었다. 그림 15는시간기준으로클라이언트버퍼크기변화를보인다. 버퍼양 ( Bytes ) 시간 ( Sec ) kbps 256 kbps 320 kbps 그림 분간재생시수신측재생되지않은버퍼량변화 수신측초기버퍼버퍼링이후재생이시작되며버퍼링된오디오스트림의재생이후수신측재생되지않은버퍼량이최소 1821 bytes ~ 최대 2195 bytes 의양을유지하는것을확인할수있다. 2분간의재생이되는동안재전송요청 / 완료과정이반복되게되며재생률에따라약간의버퍼량차이를보이며재생률이높아짐에따라재생되지않은버퍼량의차이가크게나타난다. 이는전 29

35 송률이높아짐에따라패킷사이간격이좁아지며가변적인네트워크상황에의해패킷도착시점이일정하지않기때문이다. 다음실험에서는손실된패킷발생시송신측과수신측의패킷간격을모니터링함으로서실제전송환경에서패킷간격의변화를확인한다. 5.4 재전송시송신측패킷간격변화 서버에서전송되는패킷과패킷간의시간간격을측정하였다. 패킷간의시간간격은전송률을나타내는지표로서동적으로변하는전송률을파악하기위한것이다. 전송률이각각 128Kbps, 256Kbps 그리고 320Kbps 인경우에대해서버에서전송되는전체패킷가운데 100개의패킷에대한것으로표시하였다. 그림 16은서버에서인터넷으로진입하기직전단에서측정된패킷시간간격이다. 시간간격 ( ms ) kbps 256 kbps 320 kbps 전송된패킷수 그림 16. 송신측에서측정된패킷간격변화 그림 16의결과에서정상적으로에러없이패킷을전송하는경우전송률이 128Kbps는 7.6ms ~ 8.1ms, 256Kbps는 3.5ms ~ 4ms, 320Kbps는 3ms ~ 30

36 3.2ms 정도의간격을유지한다. 그러나재전송요청을클라이언트로부터받아서서버가재전송하는경우에서버측패킷간격이최소 0.9ms ~ 최대 1.21ms의간격을보임을알수있다. 이는재전송패킷을전송할때서버는정상적인패킷과패킷사이에재전송패킷을전송하기때문이다. 5.5 재전송시수신측패킷간격변화 클라이언트에서수신되는패킷과패킷간의시간간격을측정하였다. 그림 17에정상적인패킷과재전송요청에의해수신되는패킷사이의간격을나타내었다. 그림 16에제시된결과와같은시간에클라이언트에도착하는패킷에대한모니터링결과이며서버측재전송시점에서클라이언트에도착한패킷간격을확인할수있다. 시간간격 ( ms ) kbps 256 kbps 320 kbps 전송된패킷수 그림 17. 수신측에서측정된패킷간격변화 그림 16과그림 17의비교분석결과송신측의재전송시패킷사이간격은좁아지며수신측에도착하는패킷사이간격도최소 1.1ms ~ 최대 1.23ms로좁아짐을확인할수있다. 이는일시적으로정상적인패킷과재전송된패킷이연속적으로도착하는경우이다. 31

37 제 6 장결론및향후연구과제 인터넷에서의오디오스트리밍서비스의 QoS를결정하는요인은, 전송중패킷에러율과온전한패킷이더라도재생시각이전에도착해야하는것등이다. 오디오데이터는동일하게시간제약성을가지는비디오데이터에비해전송률이상대적으로낮다. 따라서현재의인터넷에서도완벽한전송에따른완전한 QoS가보장될수있다. 그러나기존의 QoS보장기법들은완전한데이터전송을보장하지못하는점과수신측상태를즉각적으로송신측에알릴수없는문제점을가지고있다. 손실된패킷에대한선택적재전송, 왕복시간을기반으로하는동적인수신측버퍼할당, 전송률동적제어를통한버퍼유지를통해인터넷상에서클라이언트에서서버에서전송한고품질오디오데이터를손실이나지연없이수신하여서버가제공하는 QoS 그대로오디오를재생하였다. 본논문의연구결과로써동적인수신측버퍼할당과유지를통해수신측버퍼크기를최소화하여과도한버퍼할당으로인한시스템자원낭비를막을수있으며선택적재전송기법과전송률제어기법을병행하여적용함으로써수신측에서는송신측에서전송한데이터를완벽히수신하여완전한오디오 QoS를보장할수있다. 이러한연구결과의응용으로는인터넷을사용한고품질음성서비스, 인터넷강의, 멀티미디어서비스에활용될수있다. 향후연구과제로는고품질오디오스트리밍서비스기술을이용하는인터넷콘서트, 현장감넘치는스포츠중계, 그리고고품질전화 / 음성회의서비스를연구할계획이다. 본논문에서는고품질 (128Kbps 이상재생률을가지는 ) 오디오스트리밍서비스를위해세가지기법을복합적으로적용하는 QoS보장기법을제안하였다. 32

38 참고문헌 [1] Palmer. W. Agnew, and Anne S. Kellerman, Distributed Miltimedia, p. 30, Addison-Wesley, [2] James F. Kuros, Keith W. Ross, Computer Networking : A Top-Down Approach Featuring the Internet, pp. 167~268, Addison Wesley Press, [3] 강민규, 궁상환, 김동규, RTP/RTCP를이용한영상회의시스템에서오디오패킷손실보상을위한동적부가전송매커니즘개발및성능분석, 한국정보처리학회논문지, 제5권, 제10호, pp. 2641~2753, [4] 모수정, 안종석, RTP/RTCP를위한확장성있는피드백제어기법, 한국정보과학회 '98 가을학술발표논문집 (III), pp. 477~479, [5] 김태형, 스케줄링기법을적용한 VoIP환경에서의 QoS보장에관한연구, 성균관대학교정보통신대학원, 석사학위논문, [6] 최정용, 네트워크상에서의패킷손실을고려한실시간비디오-스트림재전송시스템의구현, 성균관대학교대학원, 석사학위논문, [7] 김명호, 이윤주, 멀티미디어개념및응용, 홍릉과학출판사, [8] 황연자, 차등서비스네트워크에서의 VoIP 성능향상을위한연구, 고려대학교산업정보대학원, 석사학위논문, [9] 정태욱, RTP/RTCP를이용한연속미디어데이터의흐름제어및버퍼제어기법, 광주대학교대학원, 석사학위논문, [10] 문금지, VoIP Client에서의 H.323의 RAS Message 구현과적용모델, 숭실대학교대학원, 석사학위논문, [11] Colin Perkins, Orion Hodson, and Vicky Hardman, A Survey of Packet Loss Recovery Techniques for Streaming Audio, Readings in 33

39 Multimedia Computing and Networking, pp. 607~615, Morgan Kaufmann, [12] Jean-Chrysostome Bolt, Sacha Fosse-Parisis, Don Towsley, Adaptive FEC-Based Error Control for Internet Telephony, Readings in Multimedia Computing and Networking, pp. 616~623, Morgan Kaufmann, [13] 김무중, VoIP 시스템에서통화품질향상을위한동적제어알고리즘의성능분석, 대전대학교대학원, 석사학위논문, [14] 한성우, 공간적지역성을이용한 RTCP 개선방안, 숭실대학교대학원, 석사학위논문, [15] William Stallings, 데이터통신및컴퓨터통신 6/e, pp. 266~269, 사이텍미디어, [16] Bert J. Dempsey, Jorg Liebeherr, Alfred C. Weaver, On retransmission-based error control for continuous media traffic in packet-switching networks, Computer Networks and ISDN Systems, Vol 28, Issue 5, pp. 719~736, March [17] 김완규, 박규석, VOD 시스템에서클라이언트버퍼를위한전송률제어알고리즘설계및분석, 멀티미디어학회논문지, 제1권, 제1호, pp. 67~79, [18] 김윤호, 정두영, 가변에러율채널에효과적인 Stop-and-Wait ARQ 방식, 멀티미디어학회논문지, 제5권, 제2호, pp. 198~205,

40 감사의글 지난대학원생활동안많은것을가르쳐주시고본논문이완성되기까지끊임없는격려와조언으로저를이끌어주신손주영교수님께감사를드립니다. 좀더많은것을가르쳐주시기위해따뜻한격려와엄한질책을아끼시지않으시던교수님께다시한번감사드립니다. 그리고심사를맡아지도와조언을해주신박휴찬교수님과김재훈교수님께도감사를드립니다. 또한대학원생활동안제게가르침을주신류길수교수님께도감사를드립니다. 그리고지난시간동안연구실에서같이생활하며동거동락하던연구실동료및동생들에게고마움을전합니다. 실험을도와주며싫은내색한번안하던요나, 연구실의홍일점성미, 언제나친구같은말벗이되어준진우, 연구실에온지몇달안되었지만착실한진형, 가끔연구실에오지만언제나진지한말벗이되어준정우, 그리고이번에입학한신입생현근이와라경이, 그리고다른연구실이긴하지만여러가지로도움을주신성대형과, 병수씨, 귀여운후배억종이, 이모든분들게감사의마음을전합니다. 자식이잘되기만을바라시던부모님과할머님께도감사드립니다. 이제좀더어엿한사회인으로서부모님과할머님께효도할것을다짐합니다. 그리고지난 10년간나를믿고따라준사랑스러운예비신부정은이에게감사의마음을전합니다. 그리고이모든일들을가능하게해주신하느님께영광을바칩니다. 1

일반적인 네트워크의 구성은 다음과 같다

일반적인 네트워크의 구성은 다음과 같다 W5200 Errata Sheet Document History Ver 1.0.0 (Feb. 23, 2012) First release (erratum 1) Ver 1.0.1 (Mar. 28, 2012) Add a solution for erratum 1, 2 Ver 1.0.2 (Apr. 03, 2012) Add a solution for erratum 3