안녕하세요? 넷매니아즈 블로그입니다.
오랜만에 인사를 드리네요. 넷매니아즈 가족 여러분들 모두 힘든 한해 수고 많으셨습니다.
얼마 남지 않은 한해 잘 마무리하시고 따뜻한 연말 되시기를 바라겠습니다.
올 봄에 "속도로 한판 붙자! LG U+와 KT의 YouTube 다운로드 속도 비교"라는 제목의 넷매니아즈 블로그로 LG U+의 Google Global Cache(GGC) 도입 효과를 시험을 통해 소개해 드린 적이 있습니다. 이 당시 GGC 도입으로 인한 효과는 단순히 LG U+ 유무선 인터넷 가입자의 YouTube 다운로드 속도 개선이었지만 아마 많은 분들이 "앞으로 LG U+에서 이 GGC를 이용해서 무엇(서비스)을 할 것인가?"에 대해 예상하고 계셨을 것입니다.
그리고 지난 10월 16일 드디어 LG U+는 GGC 도입 이유를 밝히게 되었죠. 바로 Google TV입니다. 즉, LG U+는 LG전자를 시켜 Google TV가 내장된 STB(셋톱박스)을 개발하게 하였고, 이 STB과 자사망에 도입된 GGC를 이용하여 타사 IPTV 서비스와 차별화된 "IPTV와 Google TV가 결합된 u+ tv G 서비스"를 출시하였습니다.
LG U+는 Google TV가 출시된 열번째 통신 사업자이지만 Google TV와 IPTV가 결합된 방식으로 서비스를 제공하는 첫번째 사업자입니다.
u+ tv G 서비스에서 제공하는 주요 서비스를 요약하면 아래와 같습니다.
| 분류 |
서비스 |
|
1. 기존 IPTV 서비스
|
* 실시간 방송 보기: 채널수 126개
* 영화 및 TV 다시보기: 약 5만여개 컨텐츠 |
|
2. IPTV가 Google TV와 만나... 서비스
|
* YouTube 동영상 보기
* 크롬을 이용한 웹 서핑
* Play 스토어: 안드로이드 마켓에서 TV용 앱을 다운로드 받아 이용 |
|
3. IPTV가 Mobile과 만나... 서비스
|
* Second TV: 모바일 단말에서 실시간 방송 시청
(최대 3대의 모바일 단말에서 서로 다른 채널 시청 가능) |
이 중 관심을 끌었던 부분은
첫째, LG U+ IPTV 서비스(LiveTV & VoD)의 비디오 전달 방식은 무엇일까? (KT와 같을까? 다를까?)
둘째, Google TV(u+ tv STB)의 YouTube 비디오 요청 및 전달 방식은 일반 유선 단말(웹)의 방식과 같을까? 다를까?
세째, Second TV의 로직은 무엇이고 모바일 단말로 전달되는 비디오 전달 방식과 전송율은 어떻게 될까?
(대한민국 대표 OTT인 Pooq, Naver의 비디오 전송율 보다 클지? 작을지?)
였습니다.
이제 몇번의 블로그 연재를 통해 하나씩 살펴 보도록 하겠습니다.
LG U+ Google TV (u+ tv G) 비디오 요청 및 전달 방식 분석
▶ 1. 소개
2. TV에서 실시간 방송 시청 (LiveTV on TV)
3. TV에서 영화 및 TV 다시보기 시청 (VoD on TV)
4. TV에서 YouTube 동영상 시청 (YouTube on TV)
5. Mobile 단말에서 실시간 방송 시청 (LiveTV on Mobile)
u+ tv G 비디오 요청 및 전달 방식 요약
아래 그림은 u+ TV G 서비스의 비디오 요청 및 전달 방식을 요약해 본 것입니다.
1. LiveTV on TV (TV로 실시간 방송 보기)
■ 비디오 요청 방식
이용자가 리모콘으로 TV 방송 채널을 선택하면, u+ tv G STB(이하 STB이라 부르겠습니다)은 해당 채널에 대한 Multicast 주소(예. KBS1 = 233.18.145.192)가 포함된 IGMP Join(Report) 메시지를 LG U+ 망으로 보내고 (STB에는 각 방송 채널에 대한 Multicast 주소가 미리 provisioning되어 있음)
■ 비디오 전달 방식
IGMP Join 메시지를 수신한 LG U+ 망의 L2 스위치 혹은 라우터는 해당 Multicast 스트림(이용자가 선택한 실시간 방송)을 STB으로 전달합니다. 다음 편에서 소개해 드리겠지만 이용자의 방송 채널 요청(IGMP Join)과 무관하게 이용자와 인접한 LG U+ 망 어딘가(L2 스위치/라우터)까지 모든 방송 혹은 일부 인기 방송 채널들(Multicast 스트림)이 항상 전달되고 있습니다(Static Join). 이는 이용자가 채널 변경(Channel Zapping이라 부름)을 했을때 방송 데이터(Multicast 패킷)를 보다 빠르게 이용자 STB으로 전달하기 위함입니다.
■ 비디오 전달 특성
Multicast이므로 당연히 Transport Protocol은 UDP이며, 비디오 인코딩율(Encoding Rate)과 비디오 전달율(Streaming Rate) 모두 10Mbps입니다. 이와 같이 인코딩율과 전달율이 같을 수 있는 건 Multicast 패킷의 IP QoS를 DSCP=EF(0xb8)로 마킹하여 우선 순위를 높여 주었기 때문입니다. 즉, 인터넷 트래픽이 망에 과다 유입되어도(망 혼잡시에도) QoS 우선 순위가 높은 실시간 방송 Multicast 패킷은 전송 지연(latency)과 패킷 손실(packet loss)이 발생하지 않고 항상 먼저 전달됩니다.
2. VoD on TV (TV로 영화 및 TV 다시보기)
■ 비디오 요청 방식
이용자가 영화 혹은 TV 다시보기를 선택하면, STB은 RTSP 메시지(RTSP DESCRIBE)를 LG U+ VoD 서버로 보내고, 이 서버는 이용자의 IP 주소(정확히는 STB 앞에 설치된 IPTV 유무선 공유기의 IP 주소)를 확인하여 이용자와 가까운 VoD 스트리밍 서버의 IP 주소를 STB에 알려 줍니다. 이용자 IP 주소 기반의 Request Routing을 하는 것이죠. 그러면 STB은 이 IP 주소로 다시 RTSP 메시지(RTSP PLAY)를 보내고,
■ 비디오 전달 방식
RTSP 메시지를 수신한 VoD 스트리밍 서버는 해당 STB으로 영화 혹은 TV 다시보기 영상을 스트리밍 해 줍니다.
■ 비디오 전달 특성
해당 이용자에게만 전달되는 동영상이므로 당연히 Unicast이고 Transport Protocol은 TCP입니다(KT는 UDP 였던 것으로 기억합니다만). 비디오 인코딩율과 비디오 전달율 모두 8Mbps이며, IP QoS는 DSCP=AF41(0x88)로 마킹되어 전달됩니다. QoS 등급이 높으므로 인터넷 트래픽과 경쟁을 해도 이깁니다.
3. YouTube on TV (TV로 YouTube 동영상 보기)
■ 비디오 요청 방식
YouTube 앱(App)은 디폴트로 STB에 설치 되어 있습니다. 이 앱을 통해 YouTube 동영상을 선택하면 STB에서 HTTP GET 메시지가 나가게 되는데, 이 메시지는 YouTube CDN 로직에 의해 미국에 있는 YouTube 서버가 아닌 LG U+ IDC(Internet Data Center)에 위치한 Google Global Cache(GGC)로 전달되고
■ 비디오 전달 방식
GGC는 STB으로 HTTP 200 OK 메시지와 함께 YouTube 영상을 전달합니다.
■ 비디오 전달 특성
역시 해당 이용자에게만 전달되는 동영상이므로 Unicast이고 Transport Protocol은 TCP입니다. YouTube의 전통적인 전달 방식인 Progressive Download 방식으로 동영상 파일이 전달되며 IP QoS는 인터넷과 동일한 등급인 Best Effort입니다. 즉, QoS 보장을 해 주지 않습니다. 하지만 비디오 인코딩율 보다 훨씬 빠르게 동영상을 다운로드 해주고(예. 인코딩율=3Mbps, 다운로드 속도=80Mbps), 비디오 전달 과정에서 패킷 손실이 발생하면 TCP 재전송으로 다시 받아오면 되므로 QoS 등급이 낮아도 문제가 없습니다.
STB의 YouTube 앱은 디폴트로 720p 영상(인코딩율=3Mbps)을 요청하게 되며(HTTP GET URI에 itag=22) 360p나 1080p 영상을 선택할 수 있는 메뉴는 찾을 수 없었습니다.
또한 STB에 설치된 크롬 브라우저(웹)를 통해서도 YouTube 사이트에 접속하여 동일 동영상을 시청할 수(다운로드 받을 수) 있습니다. 다만 앱(App)과 웹(Web)은 YouTube 비디오 요청 및 전달 방식에서 약간의 차이가 있습니다. 이는 다음 시간에 소개해 드리겠습니다.
4. LiveTV on Mobile (모바일 단말로 실시간 방송 보기)
■ 서비스 개념
안드로이드 단말에 u+ tv G용 앱 설치 후 실행을 하면(또는 안드로이드 단말을 LG U+에서 제공하는 NFC 스티커에 갔다 대면 앱이 실행됨)
-
TV에서 나오고 있는 실시간 방송이 모바일 단말로도 나오게 되고,
-
그 상황에서 스마트폰 화면을 좌측 혹은 우측으로 드래그하면 TV 채널은 변경되지 않은채 모바일 단말의 채널만 변경됩니다. (엄마는 거실에서 TV로 KBS 드라마 보고, 아들은 방에서 모바일 단말로 SBS 스포츠 보고... 전 개인적으로 이런 가족 문화 싫어합니다만...)
-
그리고 마지막으로 스마트폰 화면을 위 방향으로 드래그하면 현재 스마트폰에서 시청 중인 채널이 TV에서도 나오게 됩니다.
* TV에서 제공하는 실시간 방송은 126개 채널이지만 모바일 단말에서 시청할 수 있는 채널수는 59개임 (CSP와의 계약 이슈인 듯)
* 모바일 단말에서 보이는 영상은 TV 대비 약 2~3초 늦음 (왜 그럴까요???)
* LG U+ 홈페이지를 보면 모바일 단말에서도 VoD를 시청할 수 있다고 되어 있지만 시험 결과 아직은 지원하지 않음
■ 비디오 요청 방식
이 서비스의 중심에는 STB이 있습니다. 모바일 단말의 실시간 방송 요청은 IPTV 유무선 공유기를 거쳐 STB으로 전달되고, STB에서 모바일용으로 할당된 Multicast 주소(예. KBS1 = 233.18.145.160)가 포함된 IGMP Join 메시지를 LG U+ 망으로 보내면
■ 비디오 전달 방식
IGMP Join 메시지를 수신한 LG U+ 망의 L2 스위치 혹은 라우터는 해당 Multicast 스트림(이용자가 선택한 모바일용 실시간 방송)을 STB으로 전달합니다. 그러면 STB은 이 스트림을 Unicast로 변환하여(Destination IP 주소=모바일 단말, Source IP 주소=STB) IPTV 유무선 공유기를 통해 모바일 단말로 전달합니다.
■ 비디오 전달 특성
▶ [LG U+ 망에서 댁내 STB으로] Multicast이므로 당연히 Transport Protocol은 UDP이며, 비디오 인코딩율과 비디오 전달율 모두 1.8Mbps입니다. IP QoS는 DSCP=EF(0xb8)로 마킹되어 전달되므로 QoS 보장을 받습니다.
▶ [댁내 STB에서 모바일 단말로] Multicast 패킷을 수신한 STB은 이 패킷을 Unicast로 변환 및 IP QoS 필드를 리마킹(DSCP 필드를 EF에서 AF41로 변경)하여 IPTV 유무선 공유기로 보내면, 유무선 공유기는 이 패킷을 와이파이를 통해 모바일 단말로 전달합니다. IPTV 유무선 공유기는 DSCP 값을 참조하여 와이파이 구간에서 QoS(WMM: Wi-Fi Multimedia) 보장을 해줍니다.
단말(Player)은 영상 데이터 전달 속도(streaming/download rate)가 encoding rate와 같거나 커야 문제 없이 동영상 재생을 할 수 있는데요. 그렇지 않으면 화면이 멈춰있게 되겠죠(예. YouTube 재생시 기다림/버퍼링).
통신 사업자 IPTV 서비스(Live, VoD)의 경우 자사 통신망에 QoS를 통해 대역폭 보장을 받게 할 수 있어 encoding rate와 streaming rate를 같게 할 수 있는 반면, OTT(예. YouTube, Pooq)는 통신 사업자 망에서 자사 서비스에 대한 QoS 보장이 안되므로 encoding rate 보다 streaming/download rate를 크게 하여 영상 데이터를 최대한 미리 단말(Player)로 가져다 놓습니다. 그리고 패킷 손실이 발생하면 재전송도 하구요.
결국 encoding rate와 streaming rate를 같게 하기 위해서는 통신 사업자 망에서 QoS 보장이 반드시 되어야 합니다.
Encoding rate와 streaming rate가 같게 되면 통신 사업자 입장에서 자사 통신망에 혼잡(congestion)을 줄여 줄 수 있는 장점을 갖게 됩니다.
예를 들어, 1Gbps 링크로 encoding rate=10Mbps 영상 50개를 streaming rate=10Mbps로 일정하게 전달하면 링크 대역폭을 500Mbps 사용하게 되고 나머지 대역폭은 기타 트래픽(인터넷)이 사용할 수 있는 반면, YouTube의 Progressive Download 방식으로 encoding rate=10Mbps 영상 50개를 전달하게 되는 경우, 초기 영상 데이터의 전달율이 매우 높아(예. 50~100Mbps) 1Gbps 링크를 모두 점유하려 해서 망 혼잡이 발생할 수 있습니다.
즉, 동일한 encoding rate 동영상에 대해서 전자는 망 혼잡이 발생하지 않지만 후자의 경우 통신 망에 혼잡을 유발시킬 수 있습니다. 그리고 이 혼잡은 결국 망을 공유하는 다른 이용자들에게 피해를 주게 되겠죠.
http://www.uplus.co.kr 에서 확인해 보니 현재 u+ tv G 서비스의 경우 HD가 91개 채널, SD가 44개 채널로 구성되어 있는데요. HD 채널 91개가 모두 10Mbps인지는 모르겠습니다. (제가 시험한 건 공중파 방송이었습니다.)
단순하게 HD는 모두 10Mbps, SD는 3Mbps(확인된 값은 아님)로 가정하면 약 1Gbps의 대역폭이 필요하게 되는데요. LG U+의 IPTV 전달망에 대한 정보가 없어서 잘은 모르겠지만 10Gbps 링크를 가진 라우터/스위치가 이용자와 아주 멀리 위치해 있지는 않을 것 같고 이 라우터/스위치까지는 전 채널이 다 내려 올 수도 있겠다는 생각이 듭니다.
예를 들어, 집안에 아빠가 TV를 통해 MBC를 시청하고 있으면 10Mbps로 인코딩된 영상이 망을 통해(IP multicasting) STB으로 전달되고, 그 상황에서 아들이 안드로이드 단말로 동일 채널(MBC)을 시청하고자 하면 LG U+ IPTV Headend에서 1.8Mbps로 인코딩된 영상이 망을 통해(IP multicasting) STB을 찍고 안드로이드 단말로 갑니다.
Transport Protocol은 UDP 라면 Streaming Protocol은 RTP인가요?
Wireshark에서 해당 패킷이 RTP로 디코딩되지 않는 것으로 보아 UDP 위에 바로 영상 데이터(MPEG2TS)가 실리는 것으로 예상됩니다.
U+TVG에 대한 자세한 설명 감사드립니다.
위에 언급이 되지않은 U+TV G 펌웨어 업그레이드에 관해서 궁금한 점이어서 문의드립니다.
관련해서 알고 계시다면, 답변해주시면 감사하겠습니다.
LT U+ 셋톱박스의 펌웨어 업그레이드 방식은 위에서 언급된 Unicast 방식인 HTTP GET 방식으로 이루어 지는지. 아니면 Live on TV 방식처럼 Multicast 방식으로 이루어지는지 궁금합니다.