Планиране на капацитет за VoIP

Няколко са основните неща при планиране на необходим капацитет на свързаност при внедряване на VoIP:

  • Период на пакетизация (packetization period, a.k.a. PP);
  • Пакети в секунда (a.k.a. PPS, обратно пропорционална на периода на пакетизация);
  • Капацитет на кодека (codec bandwidth, a.k.a. CBW);
  • Допълнителни байтове от Data Link/IP/UDP/RTP/tunneling хедъри (overhead, a.k.a. TOH);

Съществуват някои механизми за спестяване на капацитет като например VAD (Voice Activity Detection), известно при някои вендори като Silence Suppression, но тяхната полза е условна и зависи от средната зашуменост на средата при провеждане на VoIP разговори. В идеални условия и отчитане на културните особености на разговор при различни националности се счита, че VAD може да спести до 35% от необходимия капацитет, но е прието тези спестявания да не се отчитат при първоначално планиране на капацитет за пренос на глас по IP.

Цифровизация и период на пакетизация.

Всеки IP разговор започва с дигитализирането на аналоговият глас от човешкият говор в слушалката. Цифровизацията се извършва от DSP (Digital Signal Processor) в устройството, което получава съответната аналогова реч. DSP-тата са отговорни за преобразуването на аналоговият сигнал в цифров, и евентуално компресирането на гласа спрямо конркетен алгоритъм (кодек). При осъществяване на конферентни разговори, в които някои от участниците са аналогови, DSP-тата в централното устройство което хоства конференцията (MCU, conference bridge) са отговорни за миксирането и синхронизацията на входящите сигнали и изпращането на конферентен аудио поток към всеки от участниците в телеконференцията. При осъществяване на IP телеконференции, входящият поток към централизираното устройство е вече цифровизиран от DSP-тата преди него и енкапсулиран в IP пакети, така че MCU устройството е отговорно за миксирането и синхронизацията на входящите аудио потоци и възпроизвеждането на единен аудио поток към участниците в телеконференцията. Устройството, цифровизиращо аналоговият глас може да бъде различно в различни ситуации – voice gateway при свързаност към традиционна телефонна мрежа или аналогов телефонен апарат, или IP телефонен апарат в най-общия случай. Обикновено DSP-тата използвани във VoIP оборудването цифровизират периоди от по 10 милисекунди аналогов сигнал, които групи могат да бъдат енкапсулирани по една или повече в пакет при енкапсулацията. Периода цифровизиран глас, който се носи в един пакет се нарича период на пакетизация. Подразбиращата се стойност на Cisco VoIP оборудването е 2 периода от по 10 мсек. в пакет, което прави 20 мсек. глас на IP пакет. Стойността може да бъде настройвана, за да се увеличи или намали, но всяка настройка си има съответната цена. Намаляването на периода на пакетизация на 10 мсек. глас в пакет ще означава прекалено много пакети, което пък ще увеличи общото забавянето от енкапсулацията на пакетите, а също така и отношението глас/допълнителна информация от хедъри, защото всеки пакет трябва да бъде енкапсулиран поне в Data link (в болшинството от случаи Ethernet, със или без 802.1Q хедър), IP, UDP, и RTP хедър, а при пренос на IP глас върху тунели или криптирани връзки към гореспоменатите хедъри се добавя и различна стойност за хедър на използвания security протокол. Прекалено малък период на пакетизация общо взето дава резултат в повишени изисквания за капацитет поради прекалено голямото количество допълнителни байтове от хедъри.

Увеличаването на периода на пакетизация на повече от 30 мсек. има други ефекти. Положителната страна на големия период на пакетизация е намалено отношение на глас/допълнителна информация от хедъри, понеже в същия пакет, в който по подразбиране се носят 20 мсек. глас (или 10 при намален период), вече се носят 30 (или 40) милисекунди, при същото количество информация от хедъри. Това спестява броят пакети необходими за пренасянето на константно количество глас, и съответно спестява необходим капацитет за осъществяване на преноса. Недостатъкът на големият период на пакетизация идва оттам, че един пропуснат пакет оказва толкова по-осезаемо влияние върху качеството на разговора, колкото повече глас съдържа пакета. Оттук идва и изискване за по-голяма надеждност на end-to-end свързаността при използване на по-голям период на пакетизация – след като пакета е енкапсулиран веднъж количеството глас в него не се променя (освен ако общата големина на пакета не е по-голяма от MTU-то на някоя връзка по пътя, но това е почти абсурдно) независимо от евентуалните промени в хедъра на пакета, а всеки дропнат пакет оказва по-осезаемо влияние върху качеството на разговора.

В общия случай, решението за настройката на периода на пакетизация е решение на мрежовия оператор в зависимост от статистическата информация от проучвания (или предоставена от доставчик) за надеждност на свързаността – end-to-end загуби, end-to-end delay, и гарантиран наличен капацитет за VoIP. Наличният капацитет може да бъде общият капацитет на свързаност, или гарантираният капацитет от QoS политики на връзката. Информацията за максимално допустими загуби и забавяне от край до край може да бъде регламентирана в SLA споразумение с доставчика на свързаност.

Пакети за секунда, необходими за пренасянето на един VoIP разговор.

Производителността в пакети за секунда е от важно значение за по-нататъшните изчисления на необходимият капацитет на свързаност. От броя пакети за секунда и общият размер на един пакет с глас се изчислява необходимият капацитет в бита за секунда за пренос на един VoIP разговор.

Стойността пакети за секунда е обратно пропорционална на стойността на периода на пакетизация:

PPS = 1/(PP/1000)

За подразбирашият се период на пакетизация от 20 мсек. (PP=20 msec) стойността пакети за секунда е PPS = 1/0.02 = 50. Следователно, за пренос на цифровизиран глас с период на пакетизация 20 милисекунди на пакет, се използват 50 пакета за секунда. Зависимостта на PPS от PP е както следва:

PP = 10 msec => PPS = 100 pps;

PP = 20 msec => PPS = 50 pps;

PP = 30 msec => PPS = 34 pps;

PP= 40 msec => PPS = 25 pps;

Капацитет на използваният кодек

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

Различните кодеци използват различни алгоритми за кодиране на глас и предлагат различно качество на гласа. Размера в байтове на 20 милисекунди глас кодиран с конкретен кодек се получава:

Voice Payload (VPL) = (CBW/8) * PP/1000

например за G.711 с период на пакетизация по подразбиране 20 милисекунди:

(64000/8) * 20/1000 = 160 Байта

Ето капацитета на някои от популярните кодеци, и размера на 20 милисекунди глас спрямо тях:

Кодек Капацитет Voice payload
G.711u/a 64 Kbps 160 Байта
G.726 32/24/16 Kbps 80/60/40 Байта
G.728 16 Kbps 40 Байта
G.723 6.4/5.3 Kbps 16/13.25 Байта
G.729 8 Kbps 20 Байта
iLBC 15 Kbps 37.5 Байта
GSM 13.3 Kbps 33.25 Байта
SPX 5.5/8/11/15/18.2/24.6 Kbps 13.75/20/27.5/37.5/45.5/61.5 Байта

Общ размер на пакета

Общият размер на пакета се оформя като към размера на гласа прибавим размера на хедърите от използваните DataLink протоколи за пренос, а също и от IP енкапсулацията, UDP енкапсулацията, RTP хедъра който се използва за пренос на медия в реално време, вкл. звук, евентуално използването на security енкапсулации, като IPSec, L2TP, и др.

Data Link протоколи

Data Link протокола, използван за свързаност може да е различен, с различен тип и размер на хедъра. Ето някои от възможните DataLink протоколи с размера на хедърите които добавят:

Протокол Общ размер на хедъра
Ethernet 18 Байта (вкл. CRC без Pre-ambule)
Ethernet с IEEE 802.1Q 22 Байта
PPP 6 Байта (без начален и краен Flag)
Multilink PPP 8 Байта (за МPPP “къс вариант” frame)
Frame-Relay 4 Байта
ADSL PPPoE 30 Байта
ADSL PPPoA 8 Байта
ADSL RFC 1483 (bridged) 24Байта
DOCSIS 32 Байта

Network и Transport протоколи

Размера на IP хедъра е 20 Байта, а на транспортно ниво VoIP пакетите се пренасят от UDP. За разлика от TCP, UDP не предвижда поредна номерация на ссегментите при пренос, и не предоставя механизми за потвърждение (квитанции) на получаване и препредаване на изгубени сегменти. За пренос на медийно съдържание в реално време е най-важно съдържанието да не се предоставя с големи разлики във времезабавянето между различните части (jitter). Поради малките сегменти (20 милисекунди) глас предавани във всеки пакет, не е удачно различните части на един гласов поток да се изчакват прекалено много преди да бъдат възпроизведени в аналогов сигнал от отсрещната страна. В тази връзка, въпреки че надеждността на TCP и механизма за препредаване да би била полезна на VoIP, то докато изтече TCP timeout-a на даден пакет (20 мсек. глас), за да бъде препредаден той, съдържанието на този пакет би било безполезно. При загуба на 20 милисекунди глас, по-добрият вариант е този гласов сегмент да бъде пропуснат от аналоговият поток (нарушение на качеството на звука, макар и малко) или да бъде екстраполиран от останалото съдържание възможно най-точно, при положение, че кодека поддържа подобен механизъм. Евентуално изчакване на препредаването на този пакет би имало доста по-негативен ефект върху по-голяма част от разговора. По тези причини, за пренос на медийно съдържание на транспортно ниво се използва UDP, с размер на хедъра 8 Байта

Въпреки използването на UDP, за пренос на медийно съържание данните се енкапсулират и в RTP (Real-time Transport Protocol), който за разлика от UDP предоставя възможност за номериране на сегментите, а също и за маркиране по време, което подпомага възпроизвеждането на гласовият поток. RTP всъщност върви над UDP, използвайки портове с номера от 16384 до 32767. Използването на UDP портове дава възможност за мултиплексиране на аудио и други медийни сесии между два едни и същи крайни възела, на базата на уникални номера на портове. RTP не съдържа възможност за session multiplexing, както тази възможност се предоставя от TCP и UDP. Към хедърите от Data Link, Network(IP), и Transport(UDP) слоевете, трябва да прибавим и хедъра на RTP енкапсулацията в размер на 12 Байта.

По този начин размера на допълнителните байтове от горните слоеве (без Data Link) става 40 Байта (20 Байта IP + 8 Байта UDP + 12 Байта RTP).

Security енкапсулации

Съществуват различни механизми за тунелинг и криптиране на пакети, между които IPSec (в два различни “режима” – tunnel и transport), L2TP (Layer2 Tunneling Protocol), PPPoE (PPP over Ethernet), PPPoA (PPP over ATM), QinQ (IEEE 802.1Q Tunneling), MPLS Tunneling, GRE (Generic Router Encapsulation) и др. Ето таблица със сравнения на някои от тези допълнителни енкапсулации от гледна точка на размера на хедърите които добавят към пакета.

Протокол Общ размер на хедъра
IPSec Transport mode
с ESP хедър, използващ DES или 3DES за криптиране, и MD5 или SHA-1 за автентикация
30 – 37 Байта
IPSec Transport mode
с ESP хедър, използващ AES за криптиране, и AES-XCBC за автентикация
38 – 53 Байта
IPSec Tunnel mode
с ESP хедър, използващ DES или 3DES за криптиране, и MD5 или SHA-1 за автентикация, с добавени 20 байта заради допълнителната IP енкапсулация при tunnel mode (криптира се целият оригинален пакет, вкл. хедъра, и е необходима нова енкапсулация с IP “tunnel” хедър, за да може криптираният пакет да бъде рутиран)
50 – 57 Байта
IPSec Tunnel mode
с ESP хедър, използващ AES за криптиране, и AES-XCBC за автентикация, с добавени 20 байта заради допълнителната IP енкапсулация при tunnel mode
58 – 73 Байта
L2TP 24 Байта
GRE 24 Байта
MPLS 4 Байта
PPPoE 8 Байта

Използване на QoS i Call Admission Control

Добрата QoS политика е задължителна при прилагането на VoIP в мрежи за данни. Добрата QoS политика разчита на добро проучване на използваните приложения в дадена мрежа, капацитетните нужди на всяко едно от мрежовите приложения, маркирането на различните типове трафик с различни DiffServ етикети, и разпределянето на наличният капацитет на свързаност между различните приложения спрямо техните нужди и ефективната наличност на капацитет.

При прилагане на QoS VoIP медия трафика винаги се причислява към ef-класа, на който се гарантира приоритетна опашка с оформен стриктен максимален капацитетен лимит, за да се предотврати изяждане на капацитета за останалите класове трафик от приоритетната опашка. В зависимост от мрежовия оператор в ef-класа може да се включи само VoIP медия трафика, или също и signalling трафика, предназначен за установяване/поддръжка/разпадане на повиквания и медийни сесии, но обикновено VoIP Signalling се отделя в af31 класа.

Максималният капацитет на приоритетната опашка трябва да бъде достатъчен за определен брой едновременни обаждания. Този брой зависи от мрежовия оператор и неговите проучвания върху броя IP телефонни постове и шаблона на натовареност на телефонни обаждания по часове и по дестинации. Правилното прилагане на QoS не гарантира ефективното използване на приоритетната опашка – ако в нея има гарантиран капацитет за 10 едновременни обаждания, а реално има периоди с по 20 такива, приоритетната опашка ще бъде надхвърлена, което означава че ще има дропнати пакети от почти всички 20 обаждания, а не само от тези надвишаващи предварително преценения брой (дори и при използване на Weighted Random Early Detection, това поведение на packet dropping не би трябвало да се промени, защото в приоритетната опашка има само VoIP обаждания, които са еднакво агресивен трафик, така че пакети от различните потоци ще бъдат изпускани с еднаква тежест/вероятност).

За гарантиране на броя едновременни обаждания влизащи в приоритетната опашка и изобщо използващи заделения за VoIP капацитет се използва Call Admission Control. При надвишаване на CAC-лимитите, могат да бъдат дефинирани различни политики, като например отказване на обаждането или автоматично прехвърляне на обаждането през PSTN телефонната мрежа (Automated Alternate Routing, AAR), където то все пак ще бъде осъществено, макар и на по-висока цена. Използването на резервни връзки към PSTN tелефонната мрежа трябва да се извършва по такъв начин, че винаги да има една свободна линия, която да се използва в случай на повиквания към спешни телефонни номера (911, 112, и др.).

Забележка

Описаното планиране се отнася само за преноса на глaс върху IP в една посока.

Tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *