Promela

IPTV мрежови проблеми

Делян Делчев

delian@promela.com

Що е то IPTV?

Предоставяне на телевизионна услуга по традиционен начин чрез телевизор и транспорт базиран на IP протокол

Какво не е IPTV?

Тъй като IPTV изисква участието на телевизор в процеса, IPTV не е: WebTV – телевизия достъпвана през

Web Browser или медия клиент вграден в него

PCTV – телевизия достъпвана на PC чрез отделен медия клиент наподобяващ телевизор

Какво не е IPTV?

Тъй като IPTV изисква участието на телевизор в процеса, IPTV не е: WebTV – телевизия достъпвана през

Web Browser или медия клиент вграден в него

PCTV – телевизия достъпвана на PC чрез отделен медия клиент наподобяващ телевизор

IPTV структура

IPTV STBIP Network

(Multicast & Unicast distribution)

Receivers/Decoders

Video Routers

Cable Router

Multiplexor

Encoders

Encryptors

Multiplexor

IP turnover

Storage

Video Convertor

Encryptor

Video On Demand Server

Fast Channel Zapping &

Packet Loss Recovery

Server

Time Shift TV Server

Middleware Server

BillingServer

EPG

Teletext

Subtitles

Other Svc.

IPTV мрежовадистрибуция

В края на краищата телевизията се пренася като данни и трябва да пристигне от точка A до точка B през мрежата

Класически методза пренос на IPTV –

Multicasting

В IP (Internet) света има няколко вида пренос на данни – Unicasting (един изпращач – един получател), Broadcasting (един изпращач – всички получават), Anycasting (много изпращачи – един получател), Multicasting (един изпращач – много получатели)

Multicasting

Основно качество – трафика се движи само по веднъж по една линия, без значение колко клиента го получават

MulticastingНедостатъци

Много производители и оборудване не го обработват правилно или не поддържат правилно стандартите

Недовършен стандарт (за IPv4), поради което създава куп проблеми, или бива разширен с хиляди частни разширенийца създаващи крайна несъвместимост между различните оборудвания

Ключови проблеми – средна скорост на свързване към нова група ~50ms, средна скорост за напускане на групата ~15 секунди. Частни разширения опитват да решат този проблем (fast leave) за сметка на броя едновременно получавани групи, което създава проблеми с Picture In Picture и някой EPG-та

Три спорно съвместими механизма за сигнализация на Layer3 ниво – IGMPv1, IGMPv2, IGMPv3 Липсата на дефакто стандартен маршрутизиращ протокол за Multicasting. Днес можете да си

изберете между стандартните DVMRP, IS-IS, RIPng, mOSPF, PIM dense mode, PIM sparse mode, MSDP, mBGP и други

Поради субективната съпротива на големи мрежови производители, слаба поддръжка на стандартизирания от IEEE механизъм за сигнализация на Ethernet ниво – 802.1p/q GMRP, все още слаба поддръжка на 802.1ak MRP, което принуждава производителите на Ethernet да прилагат неефективни и вкарващи допълнителни дефекти Snooping методи – IGMP Snooping, PIM Snooping и т.н. Поради хаоса виден от по-горните точки, всички Snooping методи на практика не работят в реалния живот

IANA реално се разпадна преди да бъдат създадени процедурите за алокиране на Multicast групи глобално и днес няма стандарт и такъв механизъм за обмен на Multicasting трафик между два различни доставчика

Проблеми на класическата IPTV

Следва механизма на създаване на DVB-S или DVB-C headend. Същите продукти. Разликата е толкова малка, че ценово е под 10% между IPTV и друг Headend. Но DVB-S и DVB-C са създадени за Broadcasting без обратна връзка. Следователно IPTV системите днес не се възползват пълноценно от обратната връзка с ниско закъснение налична в IP мрежите

Използва недовършеният Multicasting за дистрибуция на данни до Set Top Box-ите, който много трудно се пренася между оператори и дори вътре в мрежата на самия оператор

Използва по-интерактивни системи от менюта на Set Top Box-ите, което изисква по-скъпи устройства с повече памет и CPU

Заради злата дума “IP” Content Owner-ите се н… втрещяват от страх и изискват повишени нива на сигурност, които не са толкова задължителни за DVB-S и DVB-C реализациите, което допълнително вдига цената на STB-тата и Headend-а

Един канал/стриим употребява завидно количество капацитет – от 4Mbit/s до 40-50Мбит/с, което поставя специални условия към скоростта и капацитета на мрежата

Комбинацията – висок капацитет на стриима + multicasting често изисква напълно пренаправяне на мрежите, което понякога удвоява цената на имплементацията

Абсолютен хаос по отношение на идеята къде да се решават проблемите – Application производителите казват – понеже това е проблем на лошия дизайн на услугата, той трябва да бъде решен с по-добър дизайн на услугата. Мрежовите производители пък потриват ръце и казват – по добре проблема да се реши в мрежата, купете си я наново, и дори нещо в повече, вкарайте Application функционалност (например VOD сървъри, TSTV сървъри) в мрежовите устройства

Тоталната липса на стандарт Трудностите с реализацията пък ограничават Business Case-то само до мрежи, които имат контрол

от край до край Неергономичност, бавно превключване на каналите, две дистанционни, лошо качество

ЛАН операторитев България

Доминират пазара на високоскоростни услуги (вероятно държат заедно повече от 60-70% от достъпа до крайните потребители)

Предоставят услуга чиято средна цена на мегабит е най-ниската в европа, а количеството капацитет и качеството на услугата са сред най-високите за европа

Удивително ниска цена на реализация на мрежата. Цената на порта на крайния потребител в активно оборудване се движи между 2-5 лева. Основните разходи са в кабели и труд

Заради ЛАН операторите България реално е (неофициално) сред първите 5 в Европа по достъпност на високоскоростен Интернет

Заради ЛАН операторите в България FTTx услугите са повече отколкото ADSL и това ни поставя сред водещите позиции в това направление в Европа

ЛАН операторитев България

- Недостатъци

Силно раздробени – над 200 си разделят 400к потребители Ако се изключат топ 10, които имат над 10к потребители средния размер

на оператор е малък 2-3к или по-малко Въпреки доминиращото им положение на пазара, операторите се

представят като Underground – нямат свое присъствие в стандартизиращите организации, нямат свое лоби, не изглежда да се опитват да го създадат, поради което конкурентните оператори, тяхното лоби и доминирането на ADSL-а като услуга в Европа създават свои преференции в ущърб на ЛАН операторите

Средния размер е прекалено малък за да бъдат реализирани самостоятелно скъпи услуги, като VoIP или още повече IPTV, където има и скъпа цена по придобиването на права за дистрибуция

Технологично мрежите на по-малките оператори изостават и пречат на растежа им или на реализирането на нови услуги

Доминиращата услуга създаваща бизнес за тях са File-sharing и Bittorrent, които позволяват рязкото им диференциране от ADSL-а. Но тези услуги са атакуваеми и често се атакуват

ЛАН операторитев България

- Технологична реализация

Типичната услуга е само пренос на Интернет до крайния клиент Реализацията е типично следната:

Нисък клас активно оборудване (Ethernet switches) за центъра на мрежата, свързано с оптични кабели или UTP, със слаба функционалност, скалируемост и производителност. По принцип липса на алтернативни маршрути за отказоустойчивост

Дълги медни сегменти вътре в сградите или между сградите свързани чрез верига от евтини неуправляеми комутатори (най-често 8 портови), без отказоустойчивост, без защита срещу токови удари, със захранване в медните кабели (реализирано по удивителен начин – това е плюс!) носещи споделени 100Mbit/s. Използваните комутатори са изключително ниско скалируеми и неуправляеми, често с производителност до 100kpps споделена между всички потребители на сегмент. По някога на един сегмент се слага управляем комутатор –TinyIP, с който се следи захранване и други параметри

Поради липсата на управляемост и контрол има проблеми със сигурността и управлението на потребителите

Скалируемостта се реализира най-често с Layer3 сегменти свързани с маршрутизатори базирани на Linux

Трафик контрола на потребител (сигурност и скорост), както и билинга се контролират от комлексни и хитро конфигурирани Линукс системи

Типичните решения на проблемите използвани в момента са (някой удивително интелигентни): Сигурност – PPPoE, Private VLAN-и, статични адреси, ARP spoofing + човешко наблюдение Отказоустойчивост на връзките – хора с резервно оборудване оправят проблемите често

минути след като са възникнали Хора, хора, хора, хора

ЛАН операторите- Проблеми за

класическа IPTV

Мрежовото оборудване, особено неуправляемия достъп не е в състояние да поддържа Multicasting. Някой от използваните комутатори имат ограничена производителност на Multicasting (под 100kpps) или пък дропват IGMP пакети. Често този проблем е нерешим, защото дори да си представим, че имате оборудване, с което да замените наличното, физическото време и усилия за замяна на 1000 комутатора е колосално и достатъчно ограничаващо, а често няма хора, които да го направят

Изключително дълги споделени сегменти на само 100Mbit/s. Понякога над 200 потребителя споделят 100Mbit/s. Ако всеки един от тях гледа различен телевизионен канал, ще им бъдат необходими минимум 800Мбит/с

Много от неуправляемите комутатори помнят път на MAC само 500 микросекунди (заради малка TCAM), което ги предизвиква да хъбят (портове получават трафик непредназначен за тях), което допълнително намалява капацитета

Заради ниските закъснения и високата скорост в Ethernet типичната характеристика на трафика е бърстова, а това създава проблем на IPTV защото прекъсва плавното и постоянно изпращане на видео към STB-тата. Повечето неуправляемо оборудване не поддържа приоритизация, или виртуални мрежи, с които да се отдели трафика, така че да се даде приоритет на IPTV-то пред бърстовете

Голямо количество трудно откриваеми загуби на пакети. Най-често поради Duplex Negotiation проблеми. Липса на отказоустойчивост.

Много слабо познание на технологията от самите оператори, което предизвиква неефективното и използване

Светлина в тунелаза мрежата

Няма нерешими проблеми Прагматичност, прагматичност, прагматичност. Не винаги най-очевидното решение е най-

добро Често повечето проблеми се решават с прост редизайн, пренаправяне на приложенията или

частичен/разумен ъпгрейд и не изискват грандиозни инвестиции Проблемите с дистрибуцията на IPTV върху Multicasting могат да бъдат заобиколени с

прехвърляне на дистрибуцията върху Unicasting. Ефективния транспорт може да бъде постигнат с Node-Peer дистрибуция от рестриимъри. Обаче наличието на PPPoE може да създаде проблеми, тъй като рестриимърите трябва да бъдат зад PPPoE концентратора. Може да се наложи редизайн с преместване на PPPoE концентратори по-близо до клиентите

Проблемите с разделянето на трафика и приоритетите могат да се решат с пренастройка или смяна на комутаторите и частично на приложно ниво (по-големи буфери на Set Top Box-овете, рестриимъри)

Проблемите с капацитета могат да се решат с увеличаване на скоростта или намаляване на броя клиенти на сегмент

Рестриимъри

Разработените от нас рестриимъри имат за цел да решат няколко важни цели: Заобикаляне на мултикастинга – чрез конвертиране на трафика от multicast на

unicast заобикаляме необходимостта от Multicasting на всякъде, и бавната подмяна на оборудване

Намаляваме частично скоростта за превключване на канал – забавянето при превключване на канал се дължи на Round-Trip-Delay-а на мрежата (типично малък), прочитането на PAT/PMT таблиците от MPEG-TS (изпращани средно на половин секунда), намирането на Key Frame и GOP (изпращани средно на 16 кадъра при 24 кадъра в секунда за MPEG2), Key Distribution Delay-а на Encryption CAS системата (от 200мс до 1 сек), буфера на Set Top Box-а между CPU-то и DSP-то за декодирането (понякога прекалено голям), бавният графичен интерфейс и на края бавното дистанционно (изпращащо по една команда на 600мс). Ние синхронизираме PAT/PMT и GOP и ги изпращаме автоматично при превключване на канал, с което намаляваме част от времето за превключване. Също така се намалява и RTT времето за видеото в мрежата. При поправяне и на Video Player-а на STB-то (за флъш на буфера на out) може да се намали времето за превключване на около половин секунда (най-вече забавено от CAS-а). С поправен Video Player или Middleware може да се възстановяват участъци със загуба на пакети поради бърстове, без да се налага буфера да се държи голям, с което се вдига допълнително ефектвността. Последното обаче не винаги може да се реализира при всяка IPTV