SLA в сетях PON

Заявка на участие в программе целевой подготовки кадров с участием
средств бюджета Новосибирской области в 2014/15 и 2015/16 учебных годах
I Форма сведений о предприятии и потребностях проектов
1. Информация о компании
Название: ООО «Предприятие «Элтекс»
Организационно-правовая форма: общество с ограниченной ответственностью
Год создания: 1992
Сфера деятельности: разработка и производство телекоммуникационного оборудования для построения
сетей связи. На предприятии осуществляется полный цикл разработки, производства, сопровождения
тестирования и технической поддержки эксплуатации оборудования.
Клиентами компании являются "Ростелеком", "Казахтелеком", "Транстелеком", МЧС, ФСО, ПС ФСБ России,
"МТТ", "Твое ТВ" (ТКТ), "Интерсвязь", "Омские кабельные сети", "Уфанет", "Башинформсвязь", "Газпромтелеком", "ПИН-телеком", "Новотелеком", "Сибирские сети" и другие.
Контакты: (383) 274-48-20 – отдел персонала, (383) 274-48-01 - приемная
e-mail: [email protected], [email protected]
Сайт: http://eltex.nsk.ru/
2.Предприятие является – самостоятельным коммерческим предприятием
3. Заявка на магистрантов в соответствии с представленными проектами
Проект 1 «Методы оптимизации зоны покрытия беспроводной сети IEEE 802.11 на
кластере точек доступа»
№ Наименование
Направление (факультет/кафедра, если
Необходимое
вуза
определены)
количество
целевых мест
1 СибГУТИ
Факультет информатики и вычислительной техники 1
230100 Информатика и вычислительная техника
2 НГТУ
Факультет автоматики и вычислительной техники 1
09.03.01 - Информатика и вычислительная техника
Проект 2 «Реализация балансировки нагрузки сервера ACS»
№ Наименование вуза Направление (факультет/кафедра, если определены) Необходимое количество
целевых мест
1 СибГУТИ
Факультет информатики и вычислительной техники 1
230100 Информатика и вычислительная техника
2 НГТУ
Факультет автоматики и вычислительной техники 1
09.03.01- Информатика и вычислительная техника
Проект 3 «SLA в сетях PON»
1 СибГУТИ/НГТУ
Факультет информатики и вычислительной техники/ 2
Факультет автоматики и вычислительной техники
Проект 4 «Автоматизация разработки UI по описанию модели данных устройства»
1 СибГУТИ/НГТУ
Факультет информатики и вычислительной техники/ 1
Факультет автоматики и вычислительной техники
II Описание проекта
Структура описания проекта 1.
«Методы оптимизации зоны покрытия беспроводной сети IEEE 802.11 на
кластере точек доступа»
1.Описание сути проекта:
Технология IEEE 802.11 широко применяется для построения домашних и
офисных(корпоративных) беспроводных сетей доступа. В простейшем случае для развертывания
сети может использоваться одна точка доступа, но в таком случае примерный радиус зоны
действия сети будет составлять порядка нескольких десятков метров. В случае необходимости
обеспечения доступности сети на большей площади возникает необходимость использовать
несколько точек доступа. При этом зона действия сети будет складываться из зон действия
каждой точки. Но в такой схеме возникают дополнительные вопросы по радиочастотному
планированию, связанные с такими проблемами как:
а) Интерференция на пресечении зон действия соседних точек доступа.
б) Возникновение «пробелов» при выходе точек доступа из строя.
Проблема интерференции связана с физической природой беспроводных каналов связи —
они являются разделяемым ресурсом между всеми участниками (точками доступа и клиентами).
Если кто-либо из них ведет передачу на заданной частоте — то остальные участники не могут
начать передачу, в противном случае мы получаем коллизию. Защита от коллизий заложена в
протокол IEEE 802.11 и реализуется через механизм сообщений RTS/CTS. Фактически
единственным действенным вариантом решения этой проблемы является распределение соседних
точек доступа по разным частотным каналам. При этом следует учитывать что соседние
частотные каналы, определенные стандартом IEEE 802.11 могут перекрываться. Например, в
диапазоне 2.4 ГГц определены частотные каналы с 1го (2412 МГц) по 14й (2484 МГц), между
соседними каналами разница составляет 5 МГц. Но современные точки доступа в 2.4 ГГц могут
использовать полосу частот либо в 20 МГц. Либо в 40 МГц. Стандарт предполагает варианты
использования и 10МГц- и 5 МГц- полосы, но на практике это не применяется из-за низкой
пропускной способности таких решений. Таким образом получается, что в 2.4 ГГц есть только 3
непересекающихся канала(если точки доступа используют полосу 20МГц) — 1, 6 и 11й. Если
точки работают в режиме 40 МГц, то в этом диапазоне невозможно разместить две точки по
частотам так. Чтобы они не оказывали влияния друг на друга.
В диапазоне 5 ГГц используются каналы:
Канал
34
36
38
40
42
44
46
48
52
56
60
64
100
104
Частота (ГГц)
5,170
5,180
5,190
5,200
5,210
5,220
5,230
5,240
5,260
5,280
5,300
5,320
5,500
5,520
108
112
116
120
124
128
132
136
140
147
149
151
153
155
157
159
161
163
165
167
171
173
177
180
5,540
5,560
5,580
5,600
5,620
5,640
5,660
5,680
5,700
5,735
5,745
5,755
5,765
5,775
5,785
5,795
5,805
5,815
5,825
5,835
5,855
5,865
5,885
5,905
Как видно из таблицы, интервал между соседними каналами составляет 10 МГц. Таким
образом, неперекрывающимися каналами являются: 36, 40, 44, 48, 52, 56, 60, 64, 100, 104, 108, 112,
116, 120, 124, и т.д.
То есть, нужна выработка алгоритма распределения точек доступа по радиочастотным
каналам.
Вторая проблема заключается в том, что даже проведя первичный анализ и запустив в работу
беспроводную сеть, нужно учитывать что точки доступа могут выходить из строя и в таких
случаях в зоне действия сети будут появляться мертвые зоны. Определенно, в таких случаях
требуется вмешательство технических служб для организации ремонта или замены оборудования.
Но ремонт/замена могут требовать достаточно большого времени, поэтому есть потребность
временного переконфигурирования сети для компенсации вышедшей точки доступа из строя. Как
правило, для «закрытия» мертвой зоны используются ресурсы соседних точек доступа. Таким
образом, при развертывании беспроводной сети нужно учитывать вышеописанные факторы и
выработать алгоритм своевременного устранения мертвых зон.
2. Краткая справка о российском и мировом уровне работ и исследований в данном
направлении
Крупные поставщики оборудования стандарта 802.11(Cisco, ARUBA и прочие) ведут интенсивные
работы в обозначенной области.
3. Описание потребителей результатов проекта
Основной целевой аудиторией проекта являются корпоративные пользователи.
4. Описание рыночной ситуации, имеющей значение для проекта
Решение проблемы радиопланирования на кластере точек доступа может быть весомым
конкурентным преимуществом проекта корпоративных беспроводных сетей.
5. Особые потребности проекта
В рамках работы над проектом возможно формирование междисциплинарной группы, потому как
затрагиваются различные аспекты работы системы:
1. Сетевое программирование.
2. Сетевая безопасность.
3. Принципы работы IEEE 802.11 на канальном и физическом уровнях.
6. Этап реализации проекта
Стадия НИР
Стадия ОКР
7. Срок реализации проекта
Менее 1-го года.
8. Предполагаемый уровень заработной платы магистра после трудоустройства от 30 т.р. (указан начальный уровень оплаты на 2014г.)
9. Партнеры компании в проекте – нет.
10. Предполагаемый вклад в ВРП области по итогам реализации проекта, а также иные
экономические показатели, имеющие значение для проекта
Экономический эффект данного проекта прогнозировать сложно.
Структура описания проекта 2.
«Реализация балансировки нагрузки сервера ACS»
1. Описание решаемой проблемы
Современные сети провайдеров услуг связи часто построены с применением абонентских
устройств различного типа, помимо персональных компьютеров, планшетов и телефонов. Это
могут быть различного вида маршрутизаторы (RG), устройства пассивной оптической сети (PON
ONT), телефонные шлюзы (VOIP GW), с поддержкой WiFi и без. Задача провайдера управлять
всем парком абонентских устройств, выполнять процедуры обновления ПО, мониторинг
состояния, оказывать помощь абонентам в настройке и т.д. В данное время на территории нашей
страны постепенно внедряется оборудование с поддержкой протокола TR-069 и его расширений
для различных типов устройств. При этом, на стороне абонентского устройства (CPE)
используется клиентская программа поддержки автоконфигурации и мониторинга по протоколу
TR-069, а на стороне провайдера устанавливается сервер TR-069 (ACS). В небольших сетях с
маленьким количеством абонентов, провайдеру достаточно иметь один физический сервер ACS с
резервированием или без него. В тех сетях, где количество абонентов исчисляется сотнями тысяч
и миллионах (например, ОАО «Ростелеком») требуется, чтобы сервера ACS были расположены в
кластере, имели возможность масштабирования. Нагрузка между серверами должна
распределяться равномерно, с учётом доступности и загруженности каждого из серверов. Задача
усложняется тем, что протокол TR-069 требует, чтобы каждое из активных абонентских устройств
обязательно сообщало о своём состоянии в строго оговоренные периоды времени. Это значит, что
в сети из миллиона активных абонентов, гарантированно в течении настроенного периода (обычно
раз в час), будет выполнено миллион обращений к серверу. В случае плановой, обычной работы
сети, эти запросы будут относительно равномерно распределены по времени. В случае нештатных
ситуаций, например, пропадание и восстановление связи с большим сегментом сети, большое
количество абонентских устройств одновременно будут пытаться установить связь с сервером.
Нужно, чтобы система корректно обработала такую ситуацию.
Для корректной работы группы серверов необходим балансировщик нагрузки, который
должен работать с учётом специфики протокола TR-069. Сам балансировщик, также, не должен
быть «узким» местом системы и должен быть выполнен, как минимум, в варианте однократного
резерва, а лучше представлять собой решение из нескольких физически разнесённых устройств,
связанных между собой протоколом, позволяющим разделять нагрузку.
Предприятие «Элтекс» разработало и выпустило в коммерческую эксплуатацию
собственный продукт «Eltex.ACS», который представляет собой сервер автоматических
конфигураций ACS. Данный сервер эксплуатируется в вариантах установки на одном сервере
либо на двух, в режиме однократного резервирования.
Целью проекта является создание программно-технического решения «Балансировщик
нагрузки сервера ACS» на базе операционной системы Linux. Данное техническое решение
должно удовлетворять следующим требованиям:
1) Работа с учётом специфики работы протокола TR-069 и реализации сервера Eltex.ACS.
2) Возможность выбора стратегии балансировки из нескольких (круговая, по загруженности
сервера, по загруженности канала и т. д.);
3) Возможность внедрения данного решения, как на промышленных серверах на базе
процессоров x86, i686, amd64, так и на серверах на базе процессоров ARM;
4) Поддержка обмена клиент-сервер по защищенному шифрованием (SSL) каналу;
5) Поддержка сессий, т. е. требование, чтобы клиентская программа общалась с одной и той
же нодой (сервером) кластера в рамках одной сессии взаимодействия.
6) Возможность резервирования (масштабирования);
7) Поддержка работы клиентских программ за NAT.
2.Краткая справка о российском и мировом уровне работ и исследований в данном
направлении
Большинство производителей ПО операторского класса, так или иначе, поставляют в
составе своего комплекса модуль, осуществляющий балансировку нагрузки на сервера системы.
Такие компании, как Cisco, Axiros, постоянно улучшают свои программные и аппаратные
комплексы, ведут исследования, продвигают продукты на рынки развитых и развивающихся
стран.
3.Потребители результата проекта
Основной целевой аудиторией проекта являются корпоративные пользователи: крупные
провайдеры телекоммуникационных услуг.
4. Описание рыночной ситуации, имеющей значение для проекта
Крупные поставщики оборудования и ПО постоянно ведут интенсивные работы в
обозначенной области. На рынке присутствуют несколько основных решений балансировки
нагрузки и масштабирования серверов. Во первых, такие крупные американские производители
коммуникационного оборудования, как Cisco и Juniper с начала двухтысячных годов продвигают
на рынке программно-аппаратные средства, позволяющие выполнять балансировку нагрузки
между серверами (Cisco ASA, Cisco CCS и др.). Во вторых, компании, продвигающие собственные
решения ACS (TR-069) предоставляют, также, и собственные проприетарные (закрытые) модули
балансировки нагрузки. В третьих, Linux-сообщество ведёт разработку открытых программных
проектов (open-source), которые выполняют требуемые функции балансировки. Но большинство
открытых проектов реализованы, в первую очередь, для балансировки HTTP-трафика (веб сайты)
и без доработки не годятся для целей протокола TR-069. Из открытых (или частично открытых
под различными лицензиями) решений, можно перечислить следующие:








HAProxy;
Ucarp;
OpenSSI;
SpreadToolkit;
Balance;
Linux Virtual Server Project (LVS);
Keepalived;
HA/FST
5.Особые потребности проекта - Нет.
6.Этап реализации проекта
На данный момент проект находится на этапе разработки замысла и оценки существующих
решений.
7.Срок реализации проекта
Рекомендуемы срок реализации проекта — до 6 месяцев.
8. Предполагаемый уровень заработной платы магистра после трудоустройства –
от 30 т.р. (указан начальный уровень оплаты на 2014г.)
9.Партнеры компании в проекте - нет.
10.Предполагаемый вклад в ВРП области по итогам реализации проекта, а также иные
экономические показатели, имеющие значение для проекта
Экономический эффект данного проекта прогнозировать сложно.
Структура описания проекта 3. «SLA в сетях PON»
1.Описание сути проекта.
В последнее время на передний план выходят вопросы качества предоставления
телекоммуникационных услуг. Сети PON как правило большие сети с десятками тысяч
пользователей. Обеспечивать заданный уровень качества услуг (SLA) в таких сетях не простая
задача.
Потенциальные проблемы накапливаются на нескольких участках: сеть агрегации, линейный
терминал, пассивная оптическая сеть, абонентский терминал. На каждом участке своя специфика
работы.
Требуется:
- провести сквозное тестирование сети,
- организовать сбор ключевых характеристик,
- проанализировать полученные данные: определить корреляцию и сопоставить с моделью сети
- визуализировать результаты, выдать рекомендации персоналу
2.Краткая справка о российском и мировом уровне работ и исследований в данном
направлении.
И в России и в мире уже есть продукты по этой теме:
WiSLA - http://www.wellink.ru/content/wisla_well_integrated_sla
eSight - http://www.huaweienterpriseusa.com/network-management-system-0/esight-sla-manager
3.Описание потребителей результатов проекта.
Операторы связи: "Ростелеком", "Казахтелеком", "Транстелеком", "МТТ", "Твое ТВ" (ТКТ),
"Интерсвязь", "Омские кабельные сети", "Уфанет", "ПИН-телеком", "Новотелеком", "Сибирские
сети" и другие.
4.Описание рыночной ситуации, имеющей значение для проекта.
Не имеет глубокого проникновения, поскольку существующие реализации дороги. Как правило,
устанавливаются «сбоку», поэтому требуется электронные устройства-пробники. На больших
сетях количество устройств-пробников будет равно количеству абонентов.
5. Особые потребности проекта:


Эффективным будет создание проектной группы из двух человек.
Организация тестирования сети и сбор исходных данных. Linux, сетевое
программирование.
Анализ и визуализация данных. СУБД, Java и т.п.
6. Этап реализации проекта в настоящее время (возможно отметить несколько)
o Разработка замысла
7. Сроки реализации проекта
o До двух лет
8. Предполагаемый уровень заработной платы магистра после трудоустройства 30 — 100 т.р.
9.Партнеры компании в проекте – нет.
10. Предполагаемый вклад в ВРП области по итогам реализации проекта, а также иные
экономические показатели, имеющие значение для проекта - не определен.
Структура описания проекта 4. «Автоматизация разработки UI по описанию
модели данных устройства»
1.Описание сути проекта: Существенную часть времени разработки телекоммуникационного
оборудования составляет разработка пользовательских интерфейсов. Визуализация, валидация
пользовательского ввода и — не простые задачи. Для сокращения времени разработки новых
продуктов и кардинального повышения качества требуется автоматизация разработки UI.
2.Краткая справка о российском и мировом уровне работ и исследований в данном
направлении.
Большинство IT компаний наверняка используют подобные механизмы, поэтому информация
должна быть в сети Интернет.
3.Описание потребителей результатов проекта.
- IT-компании
- производители телекоммуникационного оборудования
4.Описание рыночной ситуации, имеющей значение для проекта
Сроки разработки новых продуктов должны снижаться. Затраты на поддержку продуктов должны
снижаться.
5. Особые потребности проекта:
Достаточно одного магистранта.
6. Этап реализации проекта в настоящее время (возможно отметить несколько)
o Разработка замысла
7. Сроки реализации проекта
o От одного до двух лет
8. Предполагаемый уровень заработной платы магистра после трудоустройства 30 — 100 т.р.
9.Партнеры компании в проекте - нет
10. Предполагаемый вклад в ВРП области по итогам реализации проекта, а также иные
экономические показатели, имеющие значение для проекта
Не определен.