무선 및 백홀 구간 대역폭 절감을 위한 비디오 최적화 기술 Video Pacing
목 차
1 OTT 인터넷 비디오 트래픽의 통신 사업자망내 수용 방안
Wholesale CDN + HTTP Adaptive Streaming
Transparent Caching + Mobile Video Optimization
2 Video Pacing 기술
2.1 HTTP PDL의 문제점 – 무선망 대역폭 낭비
2.2 Video Pacing의 개념과 효과
2.3 Video Pacing 절차
2.4 Shaping Rate 계산


초기에 OTT 사업자들은 주로 유선망에 접속된 PC를 대상으로 인터넷 비디오 서비스를 제공했는 데 최근 들어 스마트폰/패드가 도입되면서 모바일 단말에서의 OTT 비디오 시청이 급격히 증가하고 있다.
OTT는 기존의 유선망 환경에서 사용하던 인터넷 비디오 전달 방식(특히 HTTP PDL)을 그대로 무선망 환경에도 적용하고 있어 이동 통신사업자의 무선액세스 구간과 백홀 구간에 트래픽이 폭증하고 있고 이로 인한 네트워크 비용이 증가하고 있다.
본 고에서는 이동 통신 사업자의 무선 및 백홀 구간의 대역폭 소모량을 절감시켜 주는 모바일 비디오 최적화 기술인 Video Pacing 기술에 대해 살펴 본다.


2012년 2월 22일
www.netmanias.com
NMC Consulting Group (tech@netmanias.com)

1. OTT 인터넷 비디오 트래픽의 이동 통신 사업자 망내 수용 방안

OTT의 인터넷 비디오 서비스가 전세계적으로 유행하며 성공을 거두면서 이를 뒷바침해주는 다양한 인터넷 비디오 전달 기술들이 출현하고 상용망에 적용되고 있는 데 HTTP Progressive Download (PDL)과 HTTP Adaptive Streaming 기술이 대표적이다. 실례로 유료 OTT 사업자인 Netflix가 HTTP Adaptive Streaming 방식을 사용하고 있고 무료이며 UCC 기반인 Youtube는 HTTP PDL 방식을 사용하고 있다.

초기에 OTT 사업자들은 주로 유선망에 접속된 PC를 대상으로 인터넷 비디오 서비스를 제공했는 데 최근 들어 스마트폰/패드가 도입되면서 모바일 단말에서의 OTT 비디오 시청이 급격히 증가하고 있다.

OTT는 기존의 유선망 환경에서 사용하던 인터넷 비디오 전달 방식(특히 HTTP PDL)을 그대로 무선망 환경에도 적용하고 있어 이동 통신사업자의 무선액세스 구간과 백홀 구간에 트래픽이 폭증하고 있고 이로 인한 네트워크 비용이 증가하고 있다.

Netflix와 Youtube같은 OTT의 비디오 트래픽을 자사 통신망을 통해 OTT 이용자에게 전달해주어야 하는 통신사업자는 OTT 유형에 따라 서로 다른 방식으로 자사 통신망에서의 OTT 비디오 전달을 최적화(Transit/IP 백본/백홀/무선 구간 비용 최소화, 이용자 QoE 극대화)시켜야 한다.

Netflix와 같은 유료 OTT경우 통신사업자는 자사의 Wholesale CDN 망으로 트래픽을 흡수하여 자사 통신망의 백본 네트워크 비용/Transit 비용을 절감시킬 수 있으며 또 Netflix가 이미 무선망 환경에서 최적화 비디오 기술인 HTTP Adaptive Streaming 방식을 사용하고 있기 때문에 백홀 및 무선 구간에서의 대역폭 낭비 이슈나 QoE 이슈가 없다.
즉, OTT가 통신사업자의 Wholesale CDN 서비스를 구매하고 HTTP Adaptive Streaming 방식으로 비디오를 전달하면 고맙게도 통신 사업자 유무선망 전구간에서 비디오 최적화가 달성된다.

문제는 무료형 OTT라 통신사업자 Wholesale CDN 서비스를 구매하지 않을 꺼고 비디오 전달 기술도 최적화된 기술이 아닌 HTTP PDL 방식을 사용하는 Youtube다. 즉, 통신사업자망 내부 환경을 전혀 신경 안 쓰고 통신사업자망으로 막 들어오는 막대한 Youtube 트래픽들을 어떻게 처리할 것이냐-이다. 통신사업자가 Youtube에게 “HTTP Adaptive Streaming으로 바꾸고 우리 회사 Wholesale CDN 서비스를 구매해라”라고 하면 Youtube는 “왜 내가 너한테 맞춰야 되? 니가 나한테 맞춰. 내가 더 커”라고 할 것이다.

따라서 통신 사업자는 Youtube 문제를 Youtube와 상관없이 자기 망내에서 풀어야 한다. 이에 대한 해답으로 Transparent Caching 기술이 제시되고 Level 3, Frontier, MSO 등 상용망에 도입되었다. Transparent Caching은 Wholesale CDN과 같은 효과를 주는 캐싱 기술이어서 통신사업자의 백본 증설 비용 절감 및 Transit 비용 절감의 효과를 준다. 그러나 무선 및 백홀 구간에서의 대역폭 낭비를 막아주거나 망 혼잡상황에서도 끊김 없는 화면을 제공해주는 기술은 아니다.

따라서 Transit 구간과 자사 IP 백본망 구간에서의 트래픽을 줄여준다는 측면에서 최적화 기술인 Transparent Caching 기술 하나만으로 통신사업자망 전구간을 최적화할 수는 없고 “무선 구간과 백홀 구간에서의 발생하는 대역폭 낭비와 망혼잡으로 인한 QoE 저하”를 막아줄 수 있는 기술이 추가적으로 필요한 데 이것이 모바일 비디오 최적화 (Mobile Video Optimization)기술이다. Video Pacing과 Dynamic Bit Rate Adaptation을 대표적인 비디오 최적화 기술로 들 수 있으며 2011년부터 Sprint와 Verizon Wireless 등에 도입되기 시작하고 있다

두 모바일 비디오 최적화 기술-Video Pacing과 Dynamic Bit Rate Adaptation-은 해결하고자 하는 포인트가 다른 데 본 고에서는 먼저 Video Pacing 기술에 대해 살펴 본다.

2. Video Pacing 기술

2.1 HTTP PDL의 문제점 – 무선망 대역폭 낭비
여러 통계 자료에 따르면 인터넷 비디오의 평균 재생시간은 5분 정도인데 50% 이상의 이용자가 평균적으로 60초 정도 보고 시청을 중단한다(다른 거 볼려고). 단말과 서버간에 가용 대역폭이 충분한 경우에는 60초 이내에 5분 분량의 전체 비디오 파일이 다운로드된다(그림 1).


그림 1. HTTP PDL의 문제점: 대역폭 낭비 이슈

이용자가 가입한 요금제가 정액제(Sprint 3G, KT 3G)인 경우 가입자는 보지 않은 비디오 분량이 단말에 빨리 다운로드되어도 그 만큼 돈을 더 내는 것이 아니므로 문제가 없지만 통신사업자 입장에서는 아까운 무선 구간 대역폭이 아무 의미없이 낭비되는 것이고 이로 인해 무선망 전체 품질이 떨어지게 된다. 예를 들어 통신사업자의 무선구간과 백홀 구간에서 전달된 비디오 트래픽이 하루에 10 TB라면 그 중에 절반 이상의 트래픽은 이용자가 보지 않는 트래픽이므로 5 TB이상의 데이터가 불필요하게 전달되는 것이다.
종량제라면 통신사업자가 오히려 좋겠지만 이용자 입장에서는 보지도 않은 비디오 분량에 대한 통신 비용을 통신사업자에게 지불해야 하므로 억울하다(불안해서 보겠나).

2.2 Video Pacing의 개념과 효과
Video Pacing 은 HTTP PDL의 단점인 무선 대역폭 낭비를 막아 주기 위한 기술로 그 개념과 효과가 그림 2에 나타나 있다. 통신사업자 모바일 네트워크의 GGSN/PGW 상단에 또는 내장형으로 Video Pacing 기능이 있는 Mobile Video Optimization (MVO) 장비 를 도입하여 단말과 OTT 오리진 서버간 구간을 단말과 MVO 장비, MVO 장비와 OTT 오리진 서버의 두 구간으로 스플릿시킨다. MVO 장비는 OTT 오리진 서버로부터 최대한 빠르게 다운로드 받아 버퍼링을 해놓고 MVO 장비가 단말로 전달해줄 때는 해당 비디오 파일의 원래 인코딩율을 자동으로 계산하여 인코딩율로 비디오 파일의 전송율을 Shaping(패킷레벨 쉐이핑임)하여 전달해주는 것이다. 이로 인해 MVO 장비와 단말사이에서는 인코딩율과 다운로드 속도가 같아져 마치 RTSP나 RTMP와 같은 실시간 스트리밍과 같은 효과(보는 동안만, 본만큼만 전달되는)를 준다. 이용자가 중간에 시청을 중단하면 MVO 장비는 더 이상 비디오 파일을 전달해주지 않으므로 무선 대역폭과 백홀 대역폭의 낭비는 없어지게 된다.
Video Pacing은 비디오 파일의 전송율을 조정하는 것이지 비디오 파일 자체는 수정하지 않는다. 즉 원래 OTT 오리진 서버에 있던 비디오 파일이 파일 사이즈가 100MB, 포맷은 FLV, Codec은 H.264, Frame Rate이 30 f/s, 인코딩율이 1Mbps, 해상도가 480p (853x480), 재생시간 10분인 파일이면 단말은 이와 똑 같은 파일을 MVO 장비로부터 전달받는다-천천히 받을 뿐이다.





그림 2. Mobile Video Optimization: Video Pacing 개념과 효과


2.3 Video Pacing 절차
MVO(Mobile Video Optimization) 장비는 DPI, TCP Proxy 그리고 Video Pacing 기능을 가진다. MVO 장비의 DPI 모듈은 단말이 OTT 오리진 포탈 또는 서버로 보내는 HTTP GET 메시지와 이에 대한 HTTP Response 메시지를 인터셉트(snooping)하여 HTTP Request URL, HTTP Request Header, HTTP Response Header 정보를 이용하여 이 메시지가 Video Request인지 아닌 지를 판단한다. 그림 3에 Non-Video Request인 경우에 대한 Message Flow가 나타나 있다.


그림 3. Non-Video Request 경우

① 단말은 OTT 웹페이지를 읽어 오기 위해 OTT 포탈 서버와 TCP connection을 맺는다.
② 단말은 HTTP GET 메시지를 OTT 포탈 서버로 전달한다.
③ MVO 장비는 이 메시지를 인터셉트하고 DPI(Deep Packet Inspection)를 수행하여 이 메시지가 Video Request가 아님을 알아낸다.
④ MVO 장비는 이 HTTP GET (/…/index.html) 포탈 서버로 전달한다. 이 때 패킷의 Source IP와 Destination IP는 변경되지 않는다.
⑤ OTT 포탈 서버가 웹페이지의 html 데이터가 포함된 HTTP Response (200 OK)로 응답한다.
⑥ MVO 장비는 이 HTTP 200 OK 메시지를 그대로 단말로 전달한다. 이 경우 TCP Connection은 Proxy되지 않는다.


그림 4에 Video Request인 경우에 대한 Message Flow가 나타나 있다.


그림 4. Video Request 경우: TCP Proxy and Video Pacing

① 단말은 비디오를 시청하기 위해 OTT 오리진 서버와 TCP connection을 맺는다.
② 단말은 HTTP GET (/…/avatar.flv) 메시지를 OTT 오리진 서버로 전달한다.
③ MVO 장비는 이 메시지를 인터셉트하고 DPI(Deep Packet Inspection)를 수행하여 이 메시지가 Video Request임을 알아낸다.
④ MVO 장비는 이 HTTP GET 메시지를 그대로 OTT 오리진 서버로 전달한다. 이 때 패킷의 Source IP와 Destination IP는 변경되지 않는다.
⑤ OTT 포탈 서버가 비디오 파일이 포함된 HTTP 200 OK로 응답한다.
⑥ MVO 장비가 HTTP 200 OK 메시지를 받으면 단말과 OTT 오리진 서버간의 TCP Connection을 스플릿시킨다(TCP Proxy). 즉, 단말과 MVO 장비간, MVO 장비와 OTT 오리진 서버간의 두 개의 TCP Connection을 만든다. 단말과 MVO 장비간의 TCP Connection 상의 비디오 파일 전달이 최적화(Pacing) 대상이 된다.
⑦ MVO 장비는 HTTP 200 OK 메시지를 단말로 전달한다.
⑧ OTT 오리진 서버는 MVO 장비와 OTT 오리진 서버간의 TCP connection을 통해 비디오 파일을 MVO 장비로 전달해준다 (OTT 오리진 서버 입장에서는 중간에 MVO 장비가 있는 지 모른다. 단지 어 갑자기 왜 이렇게 ACK가 빨리 오지-라고만 생각할 것이다).
⑨ MVO 장비는 비디오 파일의 인코딩율을 계산해낸다(시스코의 경우 인코딩율을 다음과 같이 계산한다. Encoding Rate = Video File Size / Total Video Duration. 여기서 Video File Size는 HTTP Response 메시지 헤더에 Content Length [byte]값이고 Total Video Duration은 HTTP Response Payload의 맨 앞부분에 있는 비디오 메타 데이타의 Total Duration[sec]이다. 그림 5의 183, 184번 패킷에서 이 값들을 읽을 수 있다).
⑩ MVO 장비는 이후 OTT 오리진 서버로부터 들어오는 비디오 파일을 버퍼링하면서 9번에서 계산된 인코딩율대로 비디오 패킷들을 Shaping하여 단말로 전달한다.


2.4 Shaping Rate 계산
여기서 이슈는 “MVO 장비가 어떻게 Shaping Rate을 정하느냐”이다. MVO 장비는 Shaping Rate의 결정할 때, OTT 오리진 서버와 연동이 없이 DPI를 통해 스스로 Shaping Rate을 결정한다. Cisco의 경우 MVO 장비가 HTTP Response 메시지와 비디오 메타 데이타를 보고 해당 비디오 컨텐츠의 인코딩율을 산출해 낸다. MVO는 DPI를 통해 해당 비디오 컨텐츠의 총 바이트 수와 재생 시간을 읽어 낸 후 해당 비디오 인코딩율을 계산한다.

Encoding Rate = Video File Size / Total Video Duration
Video File Size: HTTP Response Header의 Content Length [Byte]
Total Video Duration: 비디오 메타 데이터의 Total Duration [Sec]



HTTP/1.1 200 OK
Last-Modified: Sat, 19 Jun 2010 01:51:07 GMT
Content-Type: video/x-flv
Date: Tue, 27 Dec 2011 12:16:01 GMT
Expires: Tue, 27 Dec 2011 12:16:01 GMT
Cache-Control: private, max-age=22894
Accept-Ranges: bytes
Content-Length: 31451185
Connection: close
X-Content-Type-Options: nosniff
Server: gvs 1.0


FLV
onMetaData
duration: 255.322 [sec]
starttime: 0
totalduration: 255.322 [sec]
width: 640
height: 360
videodatarate: 862.056383703715
audiodatarate: 114.367788865567
totaldatarate: 983.448273705523
framerate: 29.9739152912792
bytelength: 31451185
canseekontime: true
sourcedata: B4A7D6705HH1327046218432722
purl:
pmsg:
httphostheader: o-o.preferred.nuq04s12.v5.lscache1.c.youtube.com

그림 5. Video Pacing: Shaping Rate의 계산

References

[1] Cisco, Cisco ASR 5000 Series Mobile Video Gateway Administration Guide Version 12.0, November 17, 2011
[2] Bytemobile, Advantages of Bytemobile’s Video Optimization Solution, Sep. 2011.
[3] Openwave, Media Optimization for Mobile Networks, June 2010
[4] Skyfire, Media Optimization Solution, 2011