Инфокоммуникационные технологии и системы
УДК 621.391 DOI: 10.14529/ctcr180306
МЕ ТОДИКА РАСЧЕТА ПАРАМЕТРОВ ЛИНИИ ДОСТУПА МУЛЬТИСЕРВИСНОЙ СЕТИ
В.И. Моисеев1'2, Б.Я. Лихтциндер2
1 Пермский государственный национальный исследовательский университет, г. Пермь, Россия,
2 Поволжский государственный университет телекоммуникаций и информатики, г. Самара, Россия
Рассматривается модель участка доступа мультисервисной сети оператора связи от магистральной линии до порта абонента. Рассмотрены факторы, влияющие на выбор параметров абонентской линии - объема исходящего пакетного буфера, полосы пропускания линии - в зависимости от набора предлагаемых услуг, тарифов и принятых в индустрии стандартов качества предоставления заданных услуг. Предлагается метод расчета допустимых параметров линии и абонентских тарифов для стандартного набора услуг: IP-телевидение, передача данных, потоковое интернет-видео. Выделены базовые технологии и протоколы, реализующие данные услуги, обозначены их параметры качества. Предусмотрена работа IP-телевидения по схеме DVB-IPTV на базе кодека H.264 поверх мультиплексора MPEG-TS в связке с протоколом RTP/UDP для IP-мультикаст вещания. В работе учитывается большая неравномерность потока видеотрафика на малых масштабах времени. Используемые характеристики потока видеотрафика подтверждены экспериментально. Услуга передачи данных представлена набором приложений на базе протокола TCP: обзор веб-страниц, потоковое видео по запросу, загрузка файлов. Параметры качества передачи пользовательских данных выбраны согласно принятым в индустрии стандартам. Оценивается влияние алгоритмов контроля скорости TCP и поведение самих приложений. Исходя из наблюдаемого поведения трафика популярных интернет-приложений, вычислены параметры качества в зависимости от характеристик абонентской линии и тарифного плана. Параметры трафика подтверждены экспериментально. В отличие от используемых операторами связи методик расчета емкости магистральных линий, в данной работе предложена методика, которая позволяет рассчитать исчерпывающий набор характеристик абонентского порта для данного тарифного плана.
Ключевые слова: мультисервисные сети связи, сеть доступа, тарификация, IP-телеви-дение, H.264, качество обслуживания, пакетный буфер, очереди с приоритетами.
Введение
Среди основных задач оператора связи - обеспечение емкости каналов в соответствии с текущей нагрузкой и поддержание показателей качества услуг (QoS). Показатели качества для таких услуг, как передача голоса, видеоконференцсвязь и IP-телевидение жестко заданы требованиями используемых технологий [1]. С другой стороны, тарифные планы для абонентов диктуются допустимой емкостью линий доступа. В свою очередь операторы интернет-ресурсов и приложений (контент-провайдеры) заинтересованы в максимально эффективной утилизации абонентской линии любой емкости. Качество IP-TV и голосовых услуг находятся в зоне ответственности оператора [2], в отличие от интернет-приложений, на качество которых оператор влиять может лишь косвенно [3]. Таким образом, оператор мультисервисной сети вынужден балансировать между необходимостью предоставлять некоторые услуги приоритетно (голос, IP-TV), а некоторые услуги по остаточному принципу (интернет). При расчете параметров абонентской линии в сетях доступа на базе Ethernet характеристики трафика различных услуг традиционно не учитываются, а в расчет берется лишь суммарная емкость опорной сети. В данной работе предла-
гается методика по расчету характеристик абонентского порта - пропускной способности, объема исходящего пакетного буфера, приоритетам очередей - для достижения конкретных показателей качества на заданном тарифном плане.
На популярных в настоящее время Ethernet-сетях критичным является участок сети доступа между абонентскими линиями и опорной магистралью. На данном коммутаторе происходит понижение скорости с магистральной до абонентской линии, следовательно, большие объемы данных буферизуются в пакетных буферах абонентского порта [4, 5]. Примем в рамках дальнейших рассуждений, что услуги голоса, IP-TV и интернет обеспечиваются единым портом доступа. Общепринято, что для обеспечения надлежащего качества трафик этих услуг должен быть приоритетным на сети оператора относительно интернет-трафика [6]. Отметим, что стандарты QoS описывают лишь приоритеты разных типов трафика, наша же задача - получить значения параметров линии численно.
1. Услуга IP-телевидения
Для доставки IP-TV рассмотрим схему DVB-IPTV в варианте трансляции H.264/MPEG-TS/RTP/UDP/IP-мультикаст [7]. Архитектура вещания подразумевает несколько уровней сегментирования/агрегации видеоданных. С точки зрения теории очередей на поток пакетов влияют конфигурации кодека H.264 и транспортного мультиплексора MPEG-TS. В кодеке H.264 набор функций кодирования и возможности целевых абонентских устройств, такие как допустимый битрейт, задаются «профилями» и «уровнями». Ограничимся в рамках рассмотрения конфигурацией H.264 профиль High10 с уровнями от 4.0 до 5.2. Структура видеотрафика весьма сложна и различается для разных параметров кодека. Стандартами H.264 и MPEG-TS описано поведение целевого декодировщика видеоданных [7] и делается акцент на эффективную утилизацию именно буфера декодировщика [8]. При этом поведение транспортной сети лишь регламентируются требованиями: не более 20 мс джиттер (рекомендовано 4 мс), не более одного видимого артефакта в час [7, 9].
Рис. 1. График зависимости средней очереди от загрузки для разных битрейтов кодека Н.264
в профиле №дМ0
Рассмотрим, как ведет себя видеторафик на 1Р-сети. На рис. 1 представлены экспериментальные данные зависимости средней очереди от нагрузки д(р) для разных уровней кодека Н.264 в профиле High10. Данные получены путем съема дампа трафика, проходящего между сервером вещания и абонентской станцией. Подобное поведение удобно аппроксимировать следующей функцией [10]:
р(д) = Ро + aq + Ьл]д, Р(д) ^Ро ^ 0, где д - максимально допустимое значение среднего размера очереди; р(д) - максимально допустимое значение коэффициента загрузки; Ро, а и Ь - постоянные коэффициенты, определяемые в процессе аппроксимации. Учитывая, что д = АЖ , где Ж - среднее время задержки в очереди, получим максимально допустимое значение коэффициента нагрузки:
Рп
X
^п
= Р0 + aXWmax + byj XW п
где - минимальное требуемое значение интенсивности обработки, обеспечивающее допустимое среднее время задержки в очереди Wmax .
Обозначив длину пакета видеотрафика через Lp [Байт], получим минимальную требуемую пропускную способность абонентской линии ^min : 8XLp
fmin =-=-Р , - [бит/с]. (1)
p0 + aXW max + byj XW max
Экспериментальным путем могут быть получены значения Ро , а , b, Lp и X, после чего определяются допустимые значения параметров линии fmin , ^min и pmax . Согласно рекомендациям
стандарта, примем Wmax = 4 мс. В рассматриваемом эксперименте длина пакетов с ethemet-заголовком была равна 1380 Б. Рассчитанные параметры линии представлены в табл. 1.
Таблица 1
Расчетные параметры линии и коэффициенты для различных видов видеотрафика H.264, профиль High10
Параметры кодека: уровень/битрейт a b Р0 пак/с pmax Mmin , пак/с fmin , Мбит/с
4.0 / 2 Мбит/с 0,036207 8,0810-4 0,630 209 0,661 316 3,49
4.1 / 4 Мбит/с 0,008474 6,45 10-8 0,630 399 0,644 620 6,85
4.2 / 5 Мбит/с 0,199928 7,99 10-5 0,450 532 0,876 607 6,71
5.0 / 11 Мбит/с 0,005559 2,77-10-8 0,792 1040 0,815 1275 14,09
5.1 / 15 Мбит/с 0,006280 5,9710-8 0,842 1510 0,879 1717 18,96
5.2 / 16 Мбит/с 0,011912 3,22 10-5 0,792 1580 0,867 1821 20,11
2. Услуга связи по передаче данных
Следующим по важности сервисом после голоса и видео мы примем «доступ в Интернет» (услуга связи по передаче данных). Под услугой «доступ в Интернет», как правило, понимают всю совокупность сервисов и приложений, предоставляемых участниками Всемирной паутины для пользователей, включая служебные протоколы. Среди популярных приложений можно выделить обзор веб-страниц, загрузку файлов, файлообмен, просмотр потокового видео [11] (табл. 2).
Таблица 2
Популярные интернет-приложения
Вид интернет-приложения Транспортные протоколы Характер трафика
Потоковое видео по запросу HTTPS/TCP QUIC Поток высокой скорости, чередующийся с перерывами по 10-20 с (см. рис. 1)
Обзор веб-страниц HTTPS/TCP Поток высокой скорости с объемом до 2-3 МБ с длительными перерывами [11]
Загрузка файлов HTTPS/TCP Непрерывный поток со скоростью, ограниченной сервером
Доступ к таким услугам регламентируется в договоре только одним параметром - суммарной тарифной полосой пропускания абонентской линии. Наибольшую нагрузку на канал абонента вызывают интернет-приложения, основанные на TCP протоколе. Все больший процент занимает потоковое интернет-видео. Пример загрузки канала трафиком потокового видео сервиса YouTube показан на рис. 2.
TCP протокол при работе стремится полностью загрузить доступный канал до начала потери трафика. При детектировании потери скорость отправки данных понижается до исчезновения потерь и вновь плавно повышается. Скорость в TCP регулируется так называемым «окном перегрузки канала» или просто «окном отправки» (Congestion window - CWND). В популярных алго-
ритмах, которые реализованы в TCP-стеках современных операционных систем, используется схема аддитивного увеличения окна отправки при отсутствии потерь и кратным уменьшением окна при перегрузке канала. Под перегрузкой канала TCP протоколом понимается отсутствие принятого вовремя подтверждения (ACK).
Рис. 2. Количество пакетов отправляемых с порта абонента за интервал 1 мс в зависимости от времени [с]
В частности, популярная реализация алгоритма TCP-NewRENO увеличивает окно линейно, тогда как реализация TCP-CUBIC [12] увеличивает окно согласно кубической функции от времени с момента пропадания последнего сегмента (рис. 3).
а) б)
Рис. 3. Пример эволюции окна отправки TCP (CWND) для алгоритма NewRENO (а) и CIBUC (б)
В реализациях TCP для центров обработки данных эффективно используется опция ECN (Explicit Congestion Notification) для приостановки потока на отправителе, не дожидаясь переполнения буфера. Но в масштабах интернета эта опция неприменима. Подчеркнем, что TCP протокол намеренно переполняет буфер порта, после чего пытается не допустить опустошения буфера, то сбрасывая скорость, то повышая вновь. Фактически заполненность буфера будет постоянно флуктуировать. Данный факт означает, что пакеты трафика будут испытывать значительные вариации задержки (джиттер). Следовательно, сервисы с заданными целевыми показателем задержки и джиттера должны обслуживаться в отдельной приоритетной очереди.
Таким образом, при наличии TCP трафика на канале абонента мы подразумеваем, что канал будет нагружен до теоретического максимума, доступного с учетом приоритета UDP. И нагрузка, скорее всего, будет чередоваться с периодами отсутствия трафика, при этом трафик будет иметь пачечный характер с пачками, равными размеру окна отправки TCP.
При условии предоставления оператором связи абоненту услуг VoIP и IP-TV отдельными пунктами договора и прописанными параметрами качества разумно вывести такой трафик в выделенные приоритетные очереди на коммутаторах доступа. Прочий TCP трафик будет получать оставшийся канал.
Введем максимальную скорость абонентской линии, определяемую технологией подключения абонентского оборудования - f^T. Будем считать, что данная скорость ограничивает суммарную пропускную способность всех сервисов абонента. Введем максимальную скорость доступную интернет-приложениям, как остаток от канала с приоритетным трафиком:
/-max _ /-max _ V^ г
J BE - Jlink Ё nsfs , (2)
s
где s - номер приоритетной услуги абонента; ns - количество услуг данного типа; f - условная пропускная способность одного экземпляра приоритетной услуги. Для голосового и видеотрафика f рассчитывается по формуле (1). Суммирование выполняется по всем приоритетным услугам абонента кроме услуг по передаче данных TCP. Здесь индекс «BE» (Best Effort) подчеркивает, что трафик данного типа обслуживается по остаточному принципу и не является приоритетным. Обратим внимание, что оператор связи дополнительно ограничивает полосу TCP до скорости,
заявленной в тарифе абонента. Скорость тарифного плана обозначим как ftar < JE. Скорость тарифного плана реализуется оператором, как правило, в виде сглаживающего шейпера либо в виде ограниченной очереди по алгоритму «дырявого ведра».
В качестве допустимой задержки отображения веб-страницы Wweb примем значение 2 с [13]. Согласно исследованиям, начиная с 2 с задержки, абонент воспринимает соединение с интернет-ресурсом как неудовлетворительное. Средний совокупный размер веб-страницы Bweb составляет 3 МБ [14]. Примем, что среднее время на передачу пакета от клиента серверу и обратно (round
trip time) мало: R << Wweb . Пренебрегая переходными процессами при установлении TCP соединения и временем на установление соединения, рассчитаем минимально необходимую полосу для удовлетворительного отображения среднестатистического веб-ресурса:
fweb = 8 • Bweb / Wweb = 12 Мбит/с.
3. Потоковое видео
В случае с потоковым видео-сервисом (таким, как YouTube) браузер пользователя кэширует данные, полученные по протоколу TCP или QUIC, кусками, эквивалентными 10-20 с проигрывания видео. Обозначим эту длительность буферизованного видео-потока Twd, примем его для примера равным 10 с. Для начала воспроизведения видео браузеру требуется загрузить в кэш эквивалентный объем данных за время, не более обозначенного ранее Wweb. Следовательно, минимально допустимая полоса для комфортного просмотра потокового видео:
f _ Tvid fcod
Jvid - „г , (3)
Wweb
где fcod - исходный битрейт видеоданных при выходе с кодека. Те же правила справедливы и при перемотке видео. Отсюда мы можем определить максимально возможный битрейт видеопотока как fcod = fvid • Wweb / Tvid . Если принять в качестве доступной видеопотоку полосы скорость доступа к веб-ресурсам из предыдущего примера, получим: fcod = fweb •Wweb / Tvid = 2,4 Мбит/с. Это значение битрейта соответствует качеству видео 480p30 (кодек H.264, High Profile). Превышение требуемой для TCP полосы над исходным битрейтом в данном случае определяется отношением времени буферизации видео к задержке на комфортное отображение веб-ресурса: Tvid / Wweb.
Выпишем следующие соотношения между скоростью абонентской линии, приоритетными сервисами и тарифом для интернет-трафика:
/ы ^ ftar + Ё nsfs , ftar ^ max(f„d, fweb ) . (4)
s
Данные соотношения позволяют оператору связи выбрать допустимые параметры тарифа абонента по известным параметрам приоритетных услуг и популярных интернет-приложений. Исходя из особенностей традиционных алгоритмов управления потоком TCP, принято [15] рассчитывать буфер для m одновременных TCP сессий по формуле R • J
Bm = Rf , (5)
-v/m
где R - среднее время передачи пакета от клиента серверу и обратно. Конкуренция TCP сессий за канал позволяет ввести -sfm в знаменателе формулы (4) для более экономного использования памяти. Показано [15], что буфер такого объема достаточен для приема данных в размере половины «окна отправки» и не успевает полностью опустошиться в моменты уменьшения «окна от-
правки». TCP на таком буфере будет поддерживать утилизацию канала в сторону абонента на уровне, близком ftar. Оптимальные размеры буфера для TCP сильно зависят от выбранного значения R . На практике большинство веб-ресурсов, используемых абонентом, расположены в границе 100 мс задержки времени доступа. Современные браузеры открывают до 5-6 TCP сессий параллельно на одно доменное имя, примем для расчетов буфера m = 5. Рассчитанный по указанным параметрам буфер для тарифа 50 Мбит/с составляет 2,236 МБ. Максимальная задержка на
таком буфере будет зависеть лишь от выбранных параметров R и л/m и в нашем случае составит 0,357 с. Для одиночного потока TCP рассчитанный нами буфер оказывается заниженным, поэтому разумно принять за показатель качества время полной загрузки среднестатистической веб-страницы именно в один поток - W1 [с]. Параметры веб-сервисов TCP, доступные абоненту, и размеры буферов для набора тарифов рассчитаны в табл. 3.
Таблица 3
Параметры веб-сервисов в зависимости от скорости тарифа
Скорость тарифа ftar, Мбит/с Доступный битрейт fCod, Мбит/с Разрешение кадра для H.264 HP Требуемый буфер порта Bm, Мбит (m = 5) Время загрузки средней вебстраницы в один поток W1, с
10 2 360p SD 0,447 2,4
20 4 480p SD 0,894 1,2
50 10 1080p HD 2,236 0,48
100 20 1440p HD 4,472 0,24
Заключение
Пользуясь известными коэффициентами для приоритетных видов трафика, оператор связи может по формуле (1) рассчитать минимальные требования к абонентской линии. Далее из соотношений (2) и (4) по характеристике линии можно получить допустимые интернет-тарифы и рассчитать их показатели качества. В частности, по формуле (3) рассчитывается битрейт доступного абоненту интернет-видео. По формуле (5) оператор связи может рассчитать необходимую емкость исходящего пакетного буфера на порту для комфортной работы TCP-приложений. Таким образом, по данной методике, оператор связи может спланировать не только емкость магистральной сети, но и исчерпывающие параметры абонентского порта для достижения заданных показателей качества на определенном наборе тарифов.
Литература/References
1. Szigeti T., Hattingh C., Barton R., Briley K. End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks. 2nd Ed. Cisco Press, 2012. 1040 p.
2. Приказ Министерства информационных технологий и связи Российской Федерации от 27.09.2007 № 113 «Об утверждении Требований к организационно-техническому обеспечению устойчивого функционирования сети связи общего пользования». URL: http://minsvyaz.ru/ru/ documents/3921/ (дата обращения: 01.02.2018). [Prikaz Ministerstva informatsionnykh tekhnologiy i svyazi Rossiyskoy Federatsii ot 27.09.2007 № 113 "Ob utverzhdenii Trebovaniy k organizatsionno-tekhnicheskomu obespecheniyu ustoychivogo funktsionirovaniya seti svyazi obshhego pol'zovaniya" [Order of Ministry of Information Technologies and Communications of Russian Federation from 27.09.2007 No. 113 "On Applying of Requirements for Organizational and Technical Measures for Robust Functioning of Public Telecommunication Networks". Available at: http://minsvyaz.ru/ru/ documents/3921/ (accessed 01.02.2018).]
3. Paxson V., Floyd S. Why We Don't Know How to Simulate the Internet. Available at: http://www.cs.ucsb.edu/~almeroth/classes/F02. 276/ papers /paxson-97.pdf (accessed 01.02.2018).
4. Warner J. Packet Buffers. Available at: https://people.ucsc.edu/~warner/buffer.html (accessed 01.02.2018).
5. Yang Y. Understanding Switch Latency White Paper. Available at: http://www.cisco.com/cZen/
us/products/collateral/switches/nexus-3000-series-switches/white_paper_c11-661939.html (accessed 2015.11.1).
6. Cisco Collaboration System Solution Reference Network Designs. Available at: http://www.cisco.eom/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab11/collab11/ cac.html (accessed 14.05.2018).
7. Transport of MPEG-2 TS Based DVB Services over IP Based Networks ETSI TS 102 034 V2.1.1. European Broadcasting Union, France, 2016. 331 p.
8. Advanced Video Coding^ for Generic Audiovisual Services, Recommendation ITU-T H.264. International Telecommunication Union, Geneve, Switzerland, 2016. 807 p.
9. Jae-Beom Lee, Hari Kalva. The VC-1 and H.264 Video Compression Standards for Broadband Video Services. Springer Science + Business Media, LLC, New York, USA, 2008. 515p. DOI: 10.1007/978-0-387-71043-3
10. Лихтциндер Б.Я. Интервальный метод анализа трафика мультисервисных сетей доступа. Самара: ПГУТИ, 2015. 121 с. [Lihtczinder B.Ya. Intervalniy metod analiza trafka multiservisnykh setey dostupa [Interval Analysis Method of Access Networks]. Samara, PSUTI Publ., 2015. 121 p.
11. Global Internet Phenomena Report 2016. Available at: https:// www.sandvine.com/trends/ global-internet-phenomena/ (accessed 05.05.2018).
12. Injong Rhee, Lisong Xu. CUBIC: A New TCP-Friendly High-Speed TCP Variant. ACM SIGOPS Operating Systems Review, 2008, vol. 42, no. 5, pp. 64-74. DOI: 10.1145/1400097.1400105
13. Mishunov D. Why Perceived Performance Matters. Available at: https://www. smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/ (accessed 05.05.2018).
14. HTTP Archive: Trends: Total Transfer Size 2016-2017. Available at: http://httparchive.org/ trends.php (accessed 05.05.2018).
15. Guido Appenzeller, Isaac Keslassy, Nick McKeown. Sizing Router Buffers. Proceedings of SIGC0MM'04, Aug. 30-Sept. 3, 2004, Portland, Oregon, USA, pp. 281-292.
Моисеев Виктор Игоревич, ведущий программист отдела информационно-вычислительных сетей Университетского центра «Интернет», старший преподаватель кафедры радиоэлектроники и защиты информации, Пермский государственный национальный исследовательский университет, г. Пермь; аспирант кафедры мультисервисных сетей и информационной безопасности, Поволжский государственный университет телекоммуникаций и информатики, г. Самара; vim@psu.ru.
Лихтциндер Борис Яковлевич, д-р техн. наук, профессор, профессор кафедры мультисер-висных сетей и информационной безопасности, Поволжский государственный университет телекоммуникаций и информатики, г. Самара; lixt@psati.ru.
Поступила в редакцию 22 мая 2018 г.
DOI: 10.14529/ctcr180306
ACCESS PORT SETTINGS ESTIMATION FOR RESIDENTIAL CUSTOMERS ON MULTISERVICE NETWORKS
V.I. Moiseev1'2, vim@psu.ru, B.Ya. Lihtsinder2, lixt@psati.ru
1 Perm State University, Perm, Russian Federation,
2 Povolzhskiy State University of Telecommunications and Informatics, Samara, Russian Federation
The problem of estimating rate plan settings on multiservice access networks is stated. Given the triple-play nature of broadband services we formulate the interconnection between the standard service set and available access port settings - output packet buffer capacity and bandwith. We dis-
cuss usual Internet Service Provider access network from the last uplink to the end-user customer equipment access port. As an industry standard we choose IP-Television, internet data transfer and streaming video as primary services. Baseline protocols of these services are stated along with respective quality of service requirements. IP-TV service is modeled according to DVB-IPTV standard with H.264 encoding using MPEG-TS multiplexing streams over RTP and UDP protocols with IP-multicast distribution. Using experimental data we show high burstiness of H.264 traffic patterns and take care of it cduring calculation of required bandwith parameters. Data transfer service represented by popular TCP-based internet applications. We are giving attention to TCP flow control algorithms and to Application level flow control. From experimental data and industry adopted baselines of internet applications we estimate quality of service parameters as a function of customer connection settings. Unlike usual ISP approximations of core links capacity, out method allows to estimate access port settings as a function of rate plan for required service set and quality of service.
Keywords: multiservice networks, access network, tariffing, IP television, H.264, service quality, package buffer, queue with priorities.
Received 22 May 2018
ОБРАЗЕЦ ЦИТИРОВАНИЯ
FOR CITATION
Моисеев, В.И. Методика расчета параметров линии доступа мультисервисной сети / В.И. Моисеев, Б.Я. Лихтциндер // Вестник ЮУрГУ. Серия «Компьютерные технологии, управление, радиоэлектроника». - 2018. - Т. 18, № 3. - С. 51-58. DOI: 10.14529Мсг180306
Moiseev V.I., Lihtsinder B.Ya. Access Port Settings Estimation for Residential Customers on Multiservice Networks. Bulletin of the South Ural State University. Ser. Computer Technologies, Automatic Control, Radio Electronics, 2018, vol. 18, no. 3, pp. 51-58. (in Russ.) DOI: 10.14529/ctcr180306