Страница 1 из 1
Вопрос к Профи (SDH)

Добавлено:
Вс 30 апр, 2006 18:23
exInspektorUGSN
В общем вопрос прост.
Имеем центр, его нужно связать допустим с 3 районами. Используем технологию коммутации каналов а не пакетов.
Допустим проектируем так в каждый район по 3 канала и в каждом районе по 3 порта. При перегрузке делать нечего.
А можно так в каждый район по 3 канала, но их можно динамически переключать в зависимости от нагрузки в конкретный район, а в районах по 4 порта. Т.е. в состоянии нормальной нагрузки в каждый район по 3 канала, а в случае перегрузки канал динамически забирается с направления, которое недогружено и отдается в направление, которое перегружено. Что то типа ДИНАМИЧЕСКОГО SDH (может термин неудачный, но я не чисто связист).
Кто-нибудь такое строил, встречал, слышал.
Технологию с коммутацией пакетов пока не обсуждаем.

Добавлено:
Вс 30 апр, 2006 19:38
AlexBT
exInspektorUGSN, исходные не совсем понятны.
3 по 64Кбита или 3 по 2Мбита?
Вообще-то такие вещи решаются с помощью мультиплексоров статического уплотнения.
DTX от ECI Telecom, Киломуксы от RAD, или мультиплексоры от Алкателя.
Можно упаковывать без потерь качества до 7 каналов в один. Однако дорого все это.
Но если у Вас есть своя оптика во все три направления или медь, которая позволяет пропустить 2 Мегабита, то зачем Вам такие заморочки?

Добавлено:
Вс 30 апр, 2006 21:56
exInspektorUGSN
AlexBT, задача общего характера. Не важно 2 Мбита или 64 к.
Про DTX знаю, но это несколько не то. Задача не упаковать нсколько в 1 а сделать что то типа SDH но который перестраивается в зависимости от нагрузки. Как перестраиваться можно прописать заранее, но управление должно зависеть от реальной нагрузки. Т.е. имеем нечто похожее на SDH. Но такой SDH должен реагировать на сигналы управления от АМТС или другого подобного узла, пошла нагрузка в данном направлении, снимаем поток с недогруженного в том же SDH и быстро переключаем. Но переключаем не в ручную, а автоматом по команде с АМТС например - направление перегружено, а задача АМТС оценить отказы по направлениям, если более установленного порога в течении установленного интервала, то требуется сформировать еще один поток в данном направлении путем переключения.
А заморочки могут быть обоснованы ценой, держать избыточные потоки, или допускать перегрузки. DTX может и подойдет, посмотрим.

Добавлено:
Ср 03 май, 2006 09:38
Связной (С)
Имеем центр, его нужно связать допустим с 3 районами
топология????
Добавлено спустя 3 минуты 29 секунд: должен реагировать на сигналы управления от АМТС
хм.. а не должна ли быть такая система "единым целым" или "продолжением" АМТС?!

Добавлено:
Ср 03 май, 2006 18:24
Wanderer
exInspektorUGSN, если используется SDH, то задача весьма проста:
следим за нагрузкой на каналах (причем во всех точках) и при необходимости формируем соответствующие команды на кросс коммутацию в SDH в каком-то внешнем компьютере с прогой на Бейсике (про Бейсик шутка). Ну а на деле я бы так не поступал.
Вообще, Связной (С), правильно ставит вопрос- дайте топологию, может что-нибудь и придумается (и желательно тип используемого оборудования).

Добавлено:
Ср 03 май, 2006 18:54
exInspektorUGSN
Wanderer, Связной (С), топология одна - SDH кольцо STM-1. Им бы управлять как-нибудь, чтоб в зависимости от нагрузки на АМТС кольцо автоматом перестраивалось. Т.е. экономически это выгодно, есть нагрузка с данного пункта - забираем с него трафик, нет ищем другое направление. Т.е смысл операции давать в точку каналы в зависимости от нагрузки, есть трафик, собираем, нет, нечего держать на направлении избыточное число каналов. Или расширять до 4 уровня, или оптимизировать всю сеть. Т.е или избыточность или интеллект сети.

Добавлено:
Чт 04 май, 2006 04:05
Связной (С)
топология одна - SDH кольцо STM-1
хм... SDH насколько помню статическая маршрутизация, ручками и предусматривает синхронную передачу и мультиплексирование VC.
бы управлять как-нибудь, чтоб в зависимости от нагрузки на АМТС кольцо автоматом перестраивалось. Т.е. экономически это выгодно, есть нагрузка с данного пункта - забираем с него трафик, нет ищем другое направление
Как вы это представляете? Есть Мукс с 16Е1, превышение нагрузки свыше 16Е1 кроме как новой платы с большим Е1 вопрос не решит... Или речь в рамках этих 16ти? Но и тогда вообще-то VC надо прописывать пути с учетом механизмов защиты в ПО управления...
Или отстал от жизни...???
Добавлено спустя 2 минуты 40 секунд:
единственное что вижу это автоматическая прокладка маршрутов (и то отданная ПО упарвления на этапе конфига сети, далее переключения защиты), НО конечные точки автоматом задать не получиться... А если не забыть что есть защита на кольцах и она бывает разная и иногда накладывает сущ. ограничения на прописку маршрутов...

Добавлено:
Чт 04 май, 2006 08:30
JK
Встречал NMS, позволяющие управлять "по расписанию"... но чтобы "по нагрузке" никогда не видел.
Тут необходимо чтобы управляющий комплекс одновременно админил и АТС и SDH.
Связной (С), если я правильно понял
exInspektorUGSN, то он хочет сыграть на двойном-тройном использовании потоков 2М внутри STM-1... ведь сумма портов Е1 на всех ADM-1 всегда больше "ширины" STM-1.


Добавлено:
Чт 04 май, 2006 09:15
Связной (С)
JK,
чтобы управляющий комплекс одновременно админил и АТС и SDH.
о чем я говорил: или это одно целое либо интегрируется...
хочет сыграть на двойном-тройном использовании потоков 2М внутри STM-1...
как?! VC-12 прописывается от А к Б от одного физического порта до другого...

Добавлено:
Чт 04 май, 2006 09:59
BEST
Связной (С),
Дак я так понял что это и нужно.
Рулить мукосом динамически на основании анализа загрузки каналов от АМТС
и VC-12 перепрописывать.
Задача в принцепе рализуемая. Но готовые решения врядли есть. Товар будет штучный. Софт придется писать, отлаживать и вылизывать долго.
Только вопрос- если это АМТС (одна зона АBC), то ЧНН будет один...
Перераспределить что-либо не особо получится.

Добавлено:
Чт 04 май, 2006 10:14
JK
Связной (С),
>о чем я говорил: или это одно целое либо интегрируется...
Я не встречал NMS которые бы это делали одновременно. Есть универсальные, но они состоят логически из отдельных секторов-кубиков... за АТС отвечает один модуль, за SDH - другой.
>как?! VC-12 прописывается от А к Б от одного физического порта до другого...
Системы высокого уровня позволяют делать. Можно коммутировать каналы "по расписанию" - например с 12:00 по 13:00 Е1 ADM-1 соединён с Е1 ADM-2, а всё остальное время с Е1 ADM-3... Оператору NMS необходимо только заранее прописать все данные и составить расписание работы.

Добавлено:
Чт 04 май, 2006 11:22
Связной (С)
JK,
Можно коммутировать каналы "по расписанию"
ну это упрощает задачу службе эксплуатации, но до динамики под анализом нагрузки далеко...
В принципе все вертиться на уровне софта управления и его интеграцией с АМТС... Железо тут лишь исполнитель...

Добавлено:
Чт 04 май, 2006 12:02
JK
Связной (С), естественно, это не задача SDH... Нужна хорошая надстройка в виде NMS, причём не низового уровня типа "управления узлом".

Добавлено:
Чт 04 май, 2006 14:43
Петрович
exInspektorUGSN, с SDH ничего не получится, потому как это физика, и переконфигурация предусматривается только при аварии... задача решается при помощи наложения на статический SDH динамического ATM или IP под управлением так называемого софт-свича

Добавлено:
Чт 04 май, 2006 14:46
exInspektorUGSN
BEST писал(а):Связной (С),
Дак я так понял что это и нужно.
Рулить мукосом динамически на основании анализа загрузки каналов от АМТС
и VC-12 перепрописывать.
Задача в принцепе рализуемая. Но готовые решения врядли есть. Товар будет штучный. Софт придется писать, отлаживать и вылизывать долго.
Только вопрос- если это АМТС (одна зона АBC), то ЧНН будет один...
Перераспределить что-либо не особо получится.
В общем понял, что готового решения нет. Спасибо за ответы.
А система не обязательно для зоны, можно и в городе применить, например деловой центр, спальные районы и т.д. нагрузка разная в зависимости от времени, подошло бы и простое расписание по перестройке сети.
Еще раз спасибо за внимание. Вопрос закрыт.

Добавлено:
Чт 04 май, 2006 14:50
Петрович
плюс еще один выход, если мало каналов... жми до 6 раз или используй частное решение под свои нужды, например удаление пауз из разговоров (емкость примерно в 4 раза в зависимости от вендора), при условии, что нет передачи данных...