서비스 사업자의 IP TV 아키텍쳐 이해
아키텍쳐 모델
IP TV 아키텍쳐는 크게 서버와, 클라이언트 STB (Set Top Box)두 개로 이루어진다.
센터간 토폴로지 (중앙 방송 센터와 중계 센터)
서버 쪽은 중앙 방송 센터와 각 지역을 커버하기 위한 중계 센터(Sub Center)가 존재한다.
중앙 방송 센터는 전체 컨텐츠와 서비스 등을 통제하며, 중계 센터는 컨텐츠에 대한 중계를 주요 역할을 목적으로 하며, 중앙 방송 센터와 중계 센터 사이는 고속 Private 네트워크를 통해서 연결이 되어 있다. 중계 센터에서는 각 가정으로 Qos 망 또는 Private 망 기반의 IP망을 이용해서 서비스를 제공하며, VOD 서비스의 Latency를 낮추기 위해서 CDN 기반의 Storage 서비스 및 Streaming 서비스를 제공한다.
주요 서비스 별 컴포넌트
서비스 모델에 따라서는 VOD 서비스, 실시간 방송 서비스, 양방향 애플리케이션 및 공통 인프라 스트럭처로 나뉘어 지는데 각각의 구성 요소를 살펴보면 다음과 같다.
VOD 서비스 (Video on demand service)
· Contents Acquisition
컨텐츠 제공자로부터 컨텐츠 (동영상) 및 그에 대한 메타 정보(타이틀, 시간, 배우 정보 등)를 가지고 오는 역할을 수행한다. FTP나 기타 파일 전송 프로토콜 등을 통해서 컨텐츠를 읽어오고 메타정보는 XML/HTTP 기반의 REST나 SOAP등을 통해서 읽어오는 구조를 취한다. 그러나 컨텐츠 확보에 있어서, 계약 등의 이슈가 있기 때문에 IP TV 서비스 제공자가 직접적으로 컨텐츠 확보를 하지 않고, 컨텐츠 Aggregator를 통해서 컨텐츠를 확보하고, 컨텐츠 Aggregator각각 컨텐츠 제공자의 특성에 맞는 컨텐츠 획득 방안 (DVD를 통한 획득, 실제 우편을 통한 획득 등)에 따라서 컨텐츠를 모은 후에, IP TV 서비스 제공자에 맞는 형태 (MPEG2 )로 재가공하여 전달한다.
IP TV 서비스 제공자는 특정 포맷과 인터페이스 포맷을 제공함으로써 컨텐츠 획득에 들어가는 인터페이스 비용을 절약하고 기술적인 표준을 유지할 수 있다.
· Encoding
확보된 VOD 컨텐츠는 서비스 형태에 맞는 파일 포맷으로 다시 인코딩이 된다.
다양한 디바이스 (모바일,HD TV,SD TV)의 해상도에 맞춰서 인코딩이 수행되며, 인코딩 효율을 줄이기 위해서 하드웨어 인코더를 사용하기도 한다.
· CA/DRM
인코딩 된 컨텐츠는 불법적인 복제를 막기 위해서 CA/DRM 처리를 한다. 이때 중요한 것은 컨텐츠 제공자 (월트디지니,픽사등)에 따라서 특정 규격이상의 안정성(복제에 대한 대비)을 요구로 하는 CA/DRM을 요구한다. 그런 CA/DRM을 통해서 VOD를 배포하는 사업자에게만 컨텐츠를 판매하기 때문에, 계약하고자 하는 컨텐츠 제공자에 따라서 CA/DRM 솔루션을 구비하는 것이 필요하다.
· Contents Storage
인코딩 되고 DRM 처리가 된 컨텐츠는 실제 서비스를 위해서 중앙 저장소 (Contents Storage)에 저장된다.
· Contents Provisioning
지역이 넓거나 가입자 수가 많은 경우에 지역 중계 센터를 설치 하는 경우가 있는데, 이런 경우, 저장된 컨텐츠는 각 지역 중계 센터로 배포 (Provisioning)된다.
지금까지 설명한 VOD 서비스의 시스템 프로세스를 정리해보면 다음과 같다.
컨텐츠 제공자(Program Provider)로부터 동영상과 메타 정보를 수집하여 전달 받고, 전달 받은 컨텐츠를 인코딩 및 DRM을 거쳐서 중앙 저장소에 저장하여 서비스를 제공하고, 넓은 지역을 서비스 할 경우, 중계 센터로 VOD 컨텐츠를 배포 하여 지역 센터를 통해서 서비스를 제공한다.
VOD 서비스의 경우 실시간 성이 아니기 때문에, 미리 인코딩 된 컨텐츠를 제공하고, 또한 Buffering이 가능하기 때문에 일반적인 인터넷 망을 통해서 서비스가 가능하다. 단 고화질의 컨텐츠를 제공하기 때문에, 일반 Public 망을 통해서 서비스 하는 경우 Buffering 시간이 길어져서 끊김현상등이 발생할 수 있고, Loading에 시간이 많이 필요하기 때문에, 일반적으로 서비스 사업자의 경우 방송센터 또는 중계센터로부터 가정까지 폐쇄된 인터넷 망(IP)을 이용하여 서비스를 제공한다. (쉽게 말해서 Qos는 보장되지 않지만, 빠른 속도의 초고속 인터넷을 사용한다.)
실시간 방송 서비스 (Live broad casting)
실시간 방송의 경우 공중파나 케이블 방송을 IP TV로 다시 재 중계 해주는 서비스로, 실시간 방송은 TV 비즈니스에 있어서 빼놓을 수 없는 핵심 서비스이다. 실시간 방송의 경우 공중파나 케이블 방송의 컨텐츠를 실시간으로 인코딩 해서 BY PASS 해주는 방식으로, VOD와는 달리 컨텐츠를 저장하지 않기 때문에 아키텍쳐 적으로는 단순할 수 있으나, 버퍼링을 사용할 수 없고, 인코딩이 실시간으로 이루어져야 하기 때문에 각 컴포넌트의 성능적인 요구 사항이 VOD 서비스에 비해서 매우 높다.
· Encoding
공중파나 케이블 방송으로부터 받은 실시간 컨텐츠를 인코딩 한다. 인코딩에 의해서 타임LACK이 발생하면 안되기 때문에, 이 타임 LACK을 최소화하기 위해서 고성능의 하드웨어 기반의 인코딩 장비를 사용한다.
· Streaming
인코딩된 실시간 방송 Stream을 각 가정까지 전송한다. 이때 VOD와 차이점은 VOD의 경우 순간 각 사용자가 보는 컨텐츠가 다르지만, 실시간 방송의 경우 같은 채널을 본다면 같은 사용자의 경우 똑 같은 컨텐츠를 보기 때문에, IP의 Unicast가 아니라 일반적으로 Multicast망을 사용한다. 이런 이유로 실시간 서비스를 제공 하기 위해서는 방송센터 à 가정까지 IP MultiCast를 지원해야 한다.
· EPG (Electronic Program Guide)
방송 프로그램 일정표이다. IP TV에서 실제 EPG 메뉴를 띄워주기도 하고, EPG 메뉴에서 방송중인 프로그램을 선택해서 이동하거나 예약 시청, 녹화 예약 등을 한다. (녹화의 경우 현재 아키텍쳐 문서에서 배제하였다. 일반적으로 IP TV 서비스 사업자는 실시간 방송에 대한 녹화를 지원하지 않는다. 기술적 문제와 저작권 문제 등)
EPG는 실시간 방송사와 연계해서 IP TV 플랫폼에 읽어오게 되고, IP TV 플랫폼에서는 플랫폼 표준 규격으로 변경하여 STB에 전송해서 EPG GUI에 맞게 출력해준다.
· Qos(Quality of Service) 네트워크 망
일반적으로 HDMI급 화질의 5.1 CH의 영상과 음성을 제공하기 위해서는 컨텐츠나 압축률에 따라 차이는 있지만 10~12Mbps의 네트워크 대역폭이 안정적으로 필요하다. 이런 이유로, 방송센터 또는 중계 센터에서 가정까지의 Qos (Quality of Service : 12Mbps의 대역폭을 항상 유지하는 인터넷 망)이 필요하다. 국내 IP TV 사업자는 실시간 방송을 위한 회선의 Qos를 보장하기 위해서 가정에 Home Network Gate Way 라는 것을 설치하여 일반 인터넷 망과 분리하여 QoS를 보장하는 서비스를 제공한다.
향상된 실시간 방송 서비스
양방향 애플리케이션 (Interactive application)
양방향 애플리케이션은 IP TV에서 실행되는 게임이나 노래방 같은 간단한 애플리케이션에서부터 EPG나 Overlap 광고 (베너, 클릭 기반의 링크)등을 지원하는 애플리케이션을 정의한다.
좀더 나아가서 PIP (Picture in Picture)와 같이 방송 중에 여러 화면을 동시에 보여주는 (예를 들어 골프 방송에서 여러 홀을 동시에 보여준다거나, 야구 방송에서 투수 쪽과 타자 쪽 화면을 동시에 보여주는 서비스) 인터페이스 역시 양방향 애플리케이션 인터페이스를 이용한다.
양방향 애플리케이션 인터페이스는 동영상 전송을 제외한 모든 IP TV 인터페이스를 포괄하는 기술적인 컴포넌트이다.
· Application Storage
애플리케이션 컨텐츠 (게임,노래방 등)를 애플리케이션 제공자가 업로드 해서 저장하는 공간이다. AppStore같이 개발자가 직접 애플리케이션을 업로드하는 개발 생태계를 가지고 있는 플랫폼의 경우 Application Storage는 일종의 개발자 포탈과 같은 인터페이스를 가지면서 애플리케이션 업로드 판매에 대한 정산등까지고 포괄하여 지원한다.
· Application Server
Application Server는 실제 애플리케이션을 구동하거나 클라이언트에 다운로드되서 작동하는 애플리케이션에 대해서 OPEN API를 제공하는 서비스를 한다.
Application Server는 기능이 다양화 될 경우 플랫폼 형태로 구성되는 경우가 있는데, OPEN API 의 기능을 제공하는 여러 단위 컴포넌트와 이 컴포넌트를 플러그인 하는 통합형 버스(BUS)를 통해 STB에 서비스를 EXPOSE하는 기능으로 구성되며 이를 흔히SDP (Service Delivery Platform)이라고 이야기 한다.
· STB VM
STB에는 다운로드 된 애플리케이션을 관리하고, 실행하는 VM(Virtual Machine:가상 머신)이 존재한다. 모바일에서 이야기 하는 안드로이드나, 바다 플랫폼등이 이러한 VM에 해당한다.
위에서 설명한 양방향 애플리케이션 실행 환경은 국내 IP TV 플랫폼에서 사용되는 ‘클라이언트 지향형 아키텍쳐’를 이야기한다. 근래에 들어서 해외의 IP TV 플랫폼인MS MediaRoom이나 국을 TV 같은 경우에는 ‘서버 지향형 아키텍쳐’를 사용하는데 그 차이점을 설명 하면 다음과 같다.
클라이언트 지향형 아키텍쳐 (Client Oriented Architecture)
이 아키텍쳐는 애플리케이션 수행 파일을 직접 STB에 다운로드 받아서 VM위에서 구동하는 방식이다. 단말에서 직접 구동되기 때문에, 단말의 여러 기능을 이용할 수 있고, 중량의 애플리케이션 서비스 (다양한 형태의 서비스)가 가능하다는 장점을 가지고 있다.
서버 지향형 아키텍쳐 (Server Oriented Architecture)
서버 지향형 아키텍쳐는 마치 WEB이나 모바일의 WAP처럼 애플리케이션은 실제 서버에 배포되고 TAG 기반의 프레젠테이션 계층(화면) 만 클라이언트로 전송되는 아키텍쳐 모델로, 애플리케이션의 비즈니스 로직이 서버에서 실행되기 때문에 저 사양 STB에서도 사용이 용이하다는 장점을 가지고 있으며, 애플리케이션의 변경과 배포가 매우 용이하다.
MS의 경우 PF(Presentation Framework)이라는 것을 사용해서 애니메이션 등을 포함한 다양한 태그 라이브러리를 통한 UI를 제공하고, 프로그래밍 모델 역시 기존의 웹 개발 방법과 유사하기 때문에 개발생산성과 개발자 확보가 쉬운 장점을 가지고 있으며, 애플리케이션의 업그레이드 등이 매우 용이하다.
얼마 전 TV 사업 진출을 선언한 구글의 경우에도 STB에 다운로드 받는 형식이 아닌 HTML5에 IP TV서비스에 적절한 표준을 추가 함으로써, 서버 지향형 아키텍쳐를 기반으로 IP TV 서비스 인프라를 제공하려는 움직임을 보이고 있다.
공통 서비스 (Common service)
공통 서비스 컴포넌트의 위의 모든 서비스를 제공하기 위해서 제공해야 하는 공통적인 기능들과 함께, 디바이스나 사용자관리와 같은 IP TV 서비스 플랫폼의 인프라를 제공하는 컴포넌트를 정의한다.
· Billing/Charging
이벤트,패키지 상품과 같이 다양한 과금 정책에 따라서 컨텐츠의 가격을 매기는 것이 Charging, 실제 신용카드나 또는 요금 정산에 포함 시켜서 과금하는 Billing으로 구성된다.
· Device Profile 관리
STB에 대한 이력과 사용자에 대한 정보를 관리한다. STB의 Firmware 버전, 다운로드 받은 소프트웨어 이력 등을 관리한다.
· Device Management
Device에 대한 Firmware Upgrade등을 관리한다.
· Authentication & Authorization
STB를 통해서 IP TV 서비스를 이용하고자 할 때, 인증 및 권한 관리를 담당한다.
IP TV에서의 킬러 컨텐츠
IP TV 비즈니스에 있어서 대부분의 수익은 VOD와, 실시간 방송, 그리고 광고에서 창출된다.
광고 수익 기반으로 VOD를 무료로 배포하거나 고품질의 VOD를 유료로 서비스해서 수익을 창출하고, 실시간 방송의 경우 기존 공중파나 케이블을 대체하기 위해서 존재한다.
전통적인 IP TV 서비스 모델에 있어서의 문제점
국내 IP TV 비즈니스 모델에서의 주요 문제점을 살펴보면 다음과 같다.
실시간 방송의 경우 케이블 사업자의 실시간 재전송 비용에 대비해서 공중파 방송사들이 IP TV 사업자에게 상당히 큰 비용의 재전송비를 요구하기 때문에, 실시간 방송 쪽의 수익률이 좋지 않은 편이다.
또한 양방향 애플리케이션의 경우 국내의 IP TV 플랫폼이 대부분 Java 기반 또는 어도비의 플래시 형태를 사용하는데, Java 플랫폼 기반의 애플리케이션의 경우 STB에 탑재되는 JVM (Java Virtual Machine)의 표준이 잘못 구현된 경우가 많고 특성이 다양한 경우가 많아서 개발에 있어서 해당 플랫폼에 대한 경험이 많이 필요하고, 테스트에 많은 시간이 소요되기 때문에, 컨텐츠 제공자가 매우 적은 편이다. 또한 플래시 기반의 컨텐츠로 조금씩 이동 하고 있으나, 플래시 플랫폼의 한계로 인해서 아주 가벼운 형태의 애플리케이션 정도만 (간단한 게임) 서비스가 제공되고 있으며, 아직까지 애플리케이션 개발 생태계가 만들어지지 않은 상태이다.
이런 상황에서, 각 통신사들은 애플리케이션의 서버 플랫폼을 만들기 위해서 SDP (Service Delivery Platform)등을 구축하려고 노력하고 있으나, 애플리케이션 개발 생태계가 확립되지 않은 상태에서 효과를 내기 어렵고 더군다나 IP TV의 핵심 컨텐츠는 애플리케이션 보다는 효과적인 VOD 서비스 및 광고 수익 모델이기 때문에, 전략적이지 못한 투자가 이루어지고 있는 상황이다.
'아키텍쳐 > 모바일' 카테고리의 다른 글
| 모바일 앱 개발을 지원하는 - Twitter fabric overview (0) | 2015.11.27 |
|---|---|
| 모바일 데이타 분석 및 사용자 분석 (3) | 2015.11.26 |
| 모바일 개발 트렌드 (1) | 2015.11.17 |
| 대용량 서비스의 트래픽을 줄이는 이미지 최적화 기술 Web-P (0) | 2015.11.12 |
| 모바일 전쟁 2라운드 시작 - 윈도우7 (0) | 2010.06.01 |