* QoS(Quality of Service)
- Packet망에서 응용서비스가 요구하는 서비스 품질을 QoS라고 한다.
- QoS에는 여러가지가 있지만, 대표적인 것으로
> Packet Loss(손실)
> Packet Delay(지연)
> Packet Delay Jitter(지연 변이)
가 존재한다.
- 데이터의 경우는 QoS의 주 이슈가 되지 않는다. Data취급 받는 경우는 다음과 같다.
> image의 경우도 데이터로 취급한다.
> audio와 video의 경우 파일 전체를 다운 받아서 local computer에서 실행할 경우 데이터로 취급한다.
- 음성과 동영상의 패킷인 경우 : 전송 지연과 지연 변이는 QoS에 결정적인 영향을 준다.
> 음성과 동영상의 경우는 QoS보장이 큰 이슈로 작용하고 있다.
* 전송지연과 지연변이(Delay and Delay Jitter)
- 네트워크의 Packet이 만들어지고 전송되어 받는데까지 걸리는 사간을 Network delay또는 Total Packet delay라고 부른다.
- Network Delay = Transmission time + Propagation time + queuing time
> Transmission time : 전송시간 = 패킷길이/전송속도
> Propagation time : 전파지연시간 = 전송 거리/빛의 속도
> Queuing time : 라우터의 buffer에 Packet이 머무는 시간 / 라우터처리속도보다 패킷이 더 빨리 올경우 Congestion이 발생
> 전송시간과 전파지연시간은 모든 패킷이 공통으로 필요로 하는 시간으로 일정하다고 볼 수 있다.
> Queuing time은 그때그때의 네트워크 망상태에 따라서 달라 질 수 있다. 이에 의해서 패킷들이 도착하는 시간은 변한다.
이는 전송지연의 이유가 되며, 지연으로 인해 패킷이 손실 될 경우 지연변이라고 한다.
* 멀티미디어 네트워크 서비스 유형 및 특징
- 서비스 유형
1) 저장 스트리밍
2) 생방송 스트리밍
3) 실시간 대화형(ex. 인터넷 전화)
- 근본적인 특징
> 전송 지연에 민감하다.
> 데이터 손실은 어느정도 허용한다.(사람이 느끼지 못하는 것이 대부분이다.)
* 저장 스트리밍 서비스
- 미디어는 서버에 저장되있다.
- 미디어 사용 요청이 오면 Client에게 전송된다.
- 스트리밍이란? client에게 모든 미디어가 도착하기 전에 Play가 시작되는 것을 말한다.
- 이경우 Packet은 자기가 Play되는 시점 전에 도착해야 한다.
> Network delay시간이 일정할 경우에는 스트리밍을 하는데 문제가 없다.
> 하지만, Network delay시간은 일정하지 않다. 이 경우를 해결하기 위해 buffering을 사용하는 것이다.
- 대화식 동작이 구현되야 한다.
> 사용자가 되감기, 일시정지, 빠른진행 등의 VCR기능을 사용할 수 있어야 한다.
> 초기 delay는 10초, VCR기능 동작시 1~2초이내에 반응을 보이면 Human Factor에서 허가가 된다.
* 생방송 멀티미디어 서비스
- 지연에 대해서 요구되는 사항이 많다.
> 패킷이 도착하는 시간이 엄격하게 제약되있다.
- 스트리밍 서비스를 한다.
- buffer에 어느정도 Packet이 쌓이면 재생이 시작하기 때문에 첫 패킷이 도착한후 몇초 후에 재생이 시작된다.
- 대화식 동작은 부분적으로 가능할 수 있다.
> 빠른 진행은 불가능(생방송의 특징), 되감기, 일시정지는 구현이 되있다면 가능 할 것이다.
* 실시간 대화형 멀티미디어 서비스
- IP전화 및 화상회의가 이에 해당된다.
- 종단간 음성은 150msec보다 작을 경우 양호한 수준이며, 400msec이하일 경우 사용이 가능하다.(Human Factor)
- 세션 시작을 위해 별도의 protocol이 존재한다.
* Internet과 멀티미디어 서비스
- TCP/UDP/IP는 지연을 보장하지 않는다.
- 응용계층에서의 기술을 통해서 최대한의 QoS를 보장할 수 있는 방법을 강구하고 있다.
- 지금까지 나온 해결책
1) 통합 서비스 접근
> 각 응용 서비스에 필요한 대역을 보장한다. 서비스 마다 대역을 새로 만들어야 하므로 현실성이 떨어진다.
> 인터넷의 근본적인 변화가 필요하며, IP계층을 수정해야 한다.
2) 차별 서비스 : 서비스에 따라서 차별화하여 제공해주자.
3) 자유방임
> 현재 그대로 사용하며, 필요하면 대역을 더 제공해주어서 congestion을 줄여 queuing time을 줄인다.
> 대역의 한계가 있으므로, 근본적인 해결이 되지 않는다.
> CDN, 응용 계층에서의 멀티캐스트
* 음성 압축(Audio compression)
- 아날로그 신호를 일정한 속도로 샘플링한다.
- 각 코딩에 따라서 방식이 다르며, 인터넷 전화의 경우 5.3kbps부터 시작된다.
* Analog-to-Digital Coding
- PCM방식 : 샘플링 > 계수화 > 부호화의 과정을 거치면서 실행된다.
> 샘플링 : 일정 시간마다 voltage값을 읽어낸다.
> 계수화 : voltage의 층을 나눈다.
> 부호화 : 계수화된 데이터를 bit로 변경한다.
- Sample 측정 주기를 잘 해야지 음성 복원에 도움이 된다.
> Nyquist정리에 의하면 채집율은 신호에 포함된 최대 주파수의 최소한 두배가 되야한다.
> 음성의 경우 최대 주파수가 4Khz이므로 채집율은 매초 8000번이 된다.
- 부호화를 할경우 음성인경우 각 샘플당 8bit로 대체 시킨다.
> 따라서 64000bit/sec의 전송 속도가 필요하게 된다.
* 비디오 압축
- 이미지 프레임을 일정속도로 플레이 하는 것
- human factor에 의해 1초에 약 30장의 이미지가 필요하다.
- 이미지의 경우는 픽셀단위로 구성되는데, 각 픽셀을 bit로 나타낸다.
- 프레임과 프레임사이에 중복되는 픽셀은 압축하여 보낸다.(용량 packet의 길이를 줄이기 위한 방법)
> 이러한 노력이 없다면 대략적인 계산으로 1초에 10^7bit을 보내야 한다.
- 동영상은 엄청난 용량이 소모될 뿐만아니라 네트워크가 바쳐주지 못하는 경우가 많다.
* 스트리밍 멀티미디어 서비스를 위한 접근법
ⓐ 응용계층에서의 지원 방법
> buffering 기능
~ 지연 변이에 대한 대책으로 버퍼링을 위해서 초기에 어느정도 지연되서 재생이 시작된다.
~ 이는 네트워크 상에서 발생할 수 있는 패킷의 지연과 지연 변이를 방지해줄 수 있다.
~ 만약, 지연이 오래되어 버퍼링이 모두 소모되면 일시정지후 버퍼링을 다시 채운후 재생을 실시한다.
> encoding과 압축으로 용량을 줄인다.
* 인터넷 멀티미디어 실행 방법
ⓐ 단순한 방법
> HTTP object로 오디오/비디오 파일을 local computer에 다운 받은후 클라이언트의 media play에서 실행
> 스트리밍 방법이 아니고, play할 때까지 오랜 시간이 걸린다.
ⓑ 스트리밍 접근
> 웹 서버가 브라우져로 오디오/비디오 파일의 meta file을 보낸다.
> meta file은 audio/video파일의 URL과 content type정보를 갖고 있다.
> 브라우져는 media player를 시작하고, meta file을 넘겨준다.
> media player는 meta file이 지시하는데로 웹 서버에 연결하여 스트림으로 전송 받는다.
> 이 경우 웹 서버와 스트리밍 서버를 분할하여 관리 할 수도 있다.
> 이 경우 UDP를 사용하는 것이 적절하다.
~ 스트리밍 서비스의 경우 위에서 말했듯이 신뢰성에 의미가 없으며, Congestion control이 없는 것이 더 좋다.
> 서로 다른 client의 수신 속도를 처리하는 방식
~ 다른 속도로 encoding된 비디오 copy를 보관하여 client의 속도에 맞추어 전송을 실시한다.
(고/저화질 선택 기능도 이와 같은 예이다.)
> 대화식 제어 : 스트리밍 미디어 제어
~ RTSP라는 별도의 프로토콜을 사용한다.
~ RTSP는 TCP를 사용한다.
~ RTSP는 사용자의 미디어 제어 기능을 제공해준다.
~ RTSP와 Media의 연결은 처음에 전달받는 meta file을 통해서 일치시킨다.
~ RTSP제어 메세지는 포트번호 554번을 사용한다.
ex)
1) 브라우져에 미디어가 포함될 경우 클라이언트는 meta file을 서버로 부터 전송 받는다.
2) 클라이언트는 특정 미디어 파일의 재생을 실시한다.(meta file의 RTSP 주소를 이용해 보낸다)
3) 서버는 세션을 설정하고 요청된 미디어를 스트리밍 해준다.
4) 클라이언트는 미디어를 시청할 수 있다.
5) 클라이언트는 VCR기능을 실시할 때마다 서버에 RTSP 프로토콜로 현 상태를 전송해준다.
(서버는 모두다 응답하지 않고 일정시간 마다 응답해준다. 단지 요청에 따라서 미디어를 조정할 뿐이다)
※ 세션을 나누는 이유 : 한창에 같은 서버에서 오는 미디어 정보를 구분하기 위해서!