mgw что это такое

17.11.202313.07.2022 admin 0 Comments

Media Gateway

Media Gateway (MGW, или медиашлюз) — это устройство, осуществляющее преобразование между разделенными телекоммуникационными сетями.

3GPP для IMS архитектуры определяет MGW как элемент взаимодействия IP сети с PSTN или беспроводными сетями 2G, 2,5G, PLMN, а для 3G эту функцию выполняет GGSN (GPRS Gateway Support Node).

Медиашлюз соединяет несколько различных сетей, его основной функцией является конвертация между различными вариантами передачи данных.

Медиашлюз управляется call-агентом, в IMS функция управления принадлежит MGCF(Media Gateway Control Function), оба предусматривают управление звонками и сигнальную функциональность. В 3GPP call-агент обозначают как S-CSCF (Serving Call State Control Function). Коммуникация между медиашлюзами и call-агентами достигается с помощью протоколов, таких как MGCP (Media Gateway Control Protocol), Megaco, H.248. Медиашлюз не имеет IP-интерфейсов, которые генерируют события. Каждый call-агент может контролировать ряд медиа шлюзов, для надежности они располагаются рядом в сети. Тем не менее, каждый медиашлюз может управляться только одним call-агентом и должен быть физически расположен в точке взаимодействия не IP-сети, которую он поддерживает. В силу своей природы медиашлюз и его call-агенты всегда находятся рамках одного домена провайдера услуг. Медиа шлюз не осуществляется взаимодействия с внешним миром через интерфейс агент контроля («Клиент») и через RTP потоки, в отличие от медиасервера.

Потоковые операции над медиа данными, такие как, подавление эха (echo cancellation), DTMF и прочие осуществляет MRFP (процессор функции мультимедийных ресурсов) или иначе IP медиасервер в IMS согласно 3GPP, который контролируется чаще всего SIP. Медиасервер — механизм сетевой обработки общецелевого назначения выделяется отдельным элементом, так как он добавляется к любым традиционным голосовым сетям или пакетным сетям и может быть расположен в любой точке сети. В IMS контроль медиасервера осуществляет MRFC (Media Resource Function Controller), в Cable/MSO Application Manager, в NGN терминах — Application Server. В NGN (проводной и беспроводной) архитектуре, медиасервера обрабатывают медиа потоки для агентов контроля. Агенты контроля можно назвать агентами (иногда называют «гибкий коммутатор») и / или сервер приложений. Call-агент (коммутационная логика) в 3GPP IMS терминах S-CSCF, в терминах Cable/MSO как CMTS.

Несмотря на то, что объединение функций медиашлюза и медиасервера в одном устройстве требует дополнительных усилий со стороны системных интеграторов при создании решений и ресурсов у оператора при эксплуатации, так как при таких решениях сеть должна поддерживать два протокола для одних и тех же целей, существуют устройства объединяющие эти два функционала. SIP может выполнять роль конвергентного протокола контроля медиасервера, которую не могут делать MGCP или H.248.

В отличие от агентов вызова, которые контролируют медиашлюзы, сервера приложений не имеют внутреннюю потребность в стеке MGCP или H.248 протоколах стека. Поскольку они уже имеют SIP стек для сигнализации, вендоры находят его удобным для использования для управления медиасервером. SIP медиасервер ведет себя точно так же, как на границе SIP браузеров или телефонами, так что сервер приложений, может использовать свои существующие возможности SIP для управления медиасервером. Серверы приложений также требуют расширенный набор функций медиа обработки. Call-агенты, как правило, требуют только простых функций, таких как сетевые объявления, простой DTMF, простая конференц-связь, которые могут быть удовлетворены SIP или MGCP/H.248. Но сервера приложений требуют комплекса IVR, записи и воспроизведения, VoiceXML, ASR, TTS, расширенных возможностей конференц-связи, параллельного видео. Для управления этими функциями, двух самых мощных кандидатов-XML и VoiceXML-оба используются почти исключительно с SIP.

SIP поддерживает использование методов обнаружения, таких как DNS SRV записей, так что SIP-серверы могут быть расположены динамически, в отличие от медиашлюзов, где MGCP и H.248 подходят лучше всего. С точки зрения безопасности SIP является более мощным и гибким инструментом и дает больше альтернатив, чем MGCP или H.248, так как SIP был разработан для решения задач во враждебной среде IP сетей и Интернета.

VoIP (Voice over IP) медиашлюз осуществляет преобразования между TDM (Time-Division Multiplexing) и VoIP.

Полезное

Смотреть что такое «Media Gateway» в других словарях:

Media gateway — A Media gateway is a translation device or service that converts digital media streams between disparate telecommunications networks such as PSTN, SS7, Next Generation Networks (2G, 2.5G and 3G radio access networks) or PBX. Media gateways enable … Wikipedia

Media Gateway — Pour les articles homonymes, voir Gateway. Un Media gateway est un outil ou service de conversion qui transforme et convertit des flux de médias entre des réseaux de télécommunication disparates (par exemple PSTN, SS7, Next Generation Network ou… … Wikipédia en Français

Media Gateway Control Protocol — (MGCP) est un protocole permettant de contrôler les passerelles multimédia qui assurent la conversion de la voix et de la vidéo entre les réseaux IP et le Réseau Téléphonique Commuté (RTC). L architecture de base et l interface de programmation… … Wikipédia en Français

Media Gateway Control Protocol (MGCP) — Internet protocol suite Application layer BGP DHCP DNS FTP HTTP … Wikipedia

Media Gateway Control Protocol — In computing, Media Gateway Control Protocol (MGCP) is a signaling and call control protocol used within a distributed Voice over IP system.MGCP is defined in RFC 3435, which obsoletes an earlier definition in RFC 2705. It superseded the Simple… … Wikipedia

Media Gateway Control Protocol — Das Media Gateway Control Protocol (Megaco) ist ein von der IETF (RFC 3015, später RFC 3525) und der ITU T (Empfehlung H.248) gemeinsam entwickeltes Gateway Protokoll zur Steuerung von Media Gateways (MG) und wird für den Aufbau von VoIP… … Deutsch Wikipedia

Media Gateway Control Protocol (Megaco) — Megaco (officially H.248) is a gateway control protocol.[1] and an implementation of the Media Gateway Control Protocol architecture[2] for controlling media gateways in Internet Protocol (IP) networks and the public switched telephone network… … Wikipedia

Media Gateway Controller — Ein Media Gateway Controller steuert ein Media Gateway. Ein Media Gateway ist dabei stets nur Befehlsempfänger. Der Media Gateway Controller definiert, welche Medienumsetzung das Gateway an welchem logischen Datenstrom vorzunehmen hat. Je nach… … Deutsch Wikipedia

Источник

Протокол управления шлюзами MGCP

Понятие медиашлюза Для того, чтобы иметь возможность использовать телефонные сети различных типов в единой инфраструктуре были созданы устройства, называемые медиашлюзами (MGW). Эти устройства служат для преобразования различного рода аналоговых и цифровых сигналов в формат, пригодный для использования в сетях с пакетной передачей данных (например, IP). Помимо транскодирования информации, медиашлюзы обеспечивают обработку тональных сигналов, эхоподавление и […]

Понятие медиашлюза

Для того, чтобы иметь возможность использовать телефонные сети различных типов в единой инфраструктуре были созданы устройства, называемые медиашлюзами (MGW). Эти устройства служат для преобразования различного рода аналоговых и цифровых сигналов в формат, пригодный для использования в сетях с пакетной передачей данных (например, IP). Помимо транскодирования информации, медиашлюзы обеспечивают обработку тональных сигналов, эхоподавление и некоторые сопутствующие задачи.

Функционал медиашлюза может быть расширен в том случае, когда помимо преобразования сигналов, шлюз осуществляет их трансляцию во внешний мир. Такие устройства называются медиасерверами. Медиасерверы могут использоваться для изменения уже перекодированных медиапотоков, например изменения формата видеоданных.

Структура медиашлюза состоит из трех функциональных компонентов, находящихся во взаимодействии:

Архитектура устройства медиашлюза позволяет управлять несколькими шлюзами за счет одного контроллера, но необходимо, чтобы управляющий контроллер был четко определен. В случае потери связи между шлюзом и контроллером возможно резервирование и передача управления на другой, заранее определенный резервный контроллер. Информация об управляющем контроллере хранится на самом шлюзе.

Описание протокола MGCP

Аббревиатура MGCP расшифровывается как Media Gateway Control Protocol — дословно, протокол управления медиашлюзами. Он используется для обеспечения связи между шлюзами и их контроллерами. MGCP определяет среду, в которой происходит взаимодействие между этими составляющими медиашлюза. Подробное описание протокола MGCP описано в документе RFC 2705, а его структура в RFC 2805.

Понимание функций протокола управления медиашлюзами (MGCP), его компонентов и взаимосвязей, которые компоненты устанавливают друг с другом, важно при реализации масштабируемой, отказоустойчивой и безопасной среды MGCP. Среда MGCP является примером модели централизованного управления вызовами. В этом разделе описывается, как настроить MGCP на шлюзе, а также функции и возможности среды MGCP.

Протокол MGCP использует модель главный-подчиненный. Главным в данной структуре является контроллер шлюза, а подчиненным сам шлюз. Это позволяет централизованно управлять шлюзами и при необходимости, производить масштабирование сети. MGCP предоставляет контроллеру средства по управлению определенными портами на подчиненных ему шлюзах. Реализация данного протокола основана на пересылке текстовых сообщений с помощью транспортного протокола UDP по порту 2427.

Протокол MGCP обеспечивает связь между двумя типами агентов, которые именуются конечными точками и агентами вызовов.

Конечные точки. Конечными точками являются любые голосовые порты на назначенном шлюзе. Это могут быть как аналоговые (FXO/FXS), так и цифровые (T1/E1) порты. В зависимости от числа портов, один шлю может содержать несколько конечных точек. Каждая конечная точка имеет свой собственный идентификатор в формате ‘локальное имя конечной точки’@’имя шлюза’ (localID@domian), по которому к ней обращается агент вызовов. Для управления конечной точкой агент вызова должен распознать характеристики конечной точки. Чтобы упростить этот процесс, конечные точки подразделяются на несколько типов. Цель состоит в том, чтобы сконфигурировать агент вызова для управления типом конечной точки, а не для управления каждой конечной точкой индивидуально.

RFC 2705 определяет восемь типов конечных точек следующим образом:

Агенты вызовов. Агент вызова осуществляет контроль над работой шлюза и связанных с ним конечных точек, запрашивая, чтобы шлюз наблюдал и сообщал о событиях. В ответ на события агент вызова указывает конечной точке, какой сигнал, если таковой имеется, должна отправлять конечная точка подключенному телефонному оборудованию. Для этого необходимо, чтобы агент вызова распознал каждый тип конечной точки, который он поддерживает, и характеристики сигнализации каждого физического и логического интерфейса, подключенного к шлюзу.

Команды MGCP

Общение по протоколу MGCP происходит в виде обмена текстовыми сообщениями. Существует восемь основных команд MGCP, которые указаны в таблице:

Параметры отправляются вместе с командами, чтобы точно указать что требуется или какая информация предоставляется.

Инициализация вызова в протоколе MGCP

Вызовы устанавливаются путем соединения двух или более конечных точек, как показано на рисунке 5. Чтобы установить вызов, агент вызова инструктирует шлюз, связанный с каждой конечной точкой, установить соединение с определенной конечной точкой или конечной точкой определенного типа. Шлюз возвращает параметры сеанса своего соединения агенту вызова, который, в свою очередь, отправляет эти параметры сеанса другому шлюзу. С помощью этого метода каждый шлюз получает необходимые параметры сеанса для установления RTP-сессий между конечными точками. Все соединения, связанные с одним и тем же вызовом, имеют общий идентификатор вызова и используют один и тот же медиапоток. По завершении вызова агент вызова отправляет запрос на удаление соединения каждому

В среде MGCP агент вызова контролирует всю обработку установки вызова на стороне сети IP и телефонии шлюза. Поскольку шлюз связан только с одним агентом вызова одновременно, то если этот агент вызова выходит из строя или недоступен по какой-либо причине, шлюз и его конечные точки остаются неконтролируемыми и, по-сути, бесполезными. Для решения данной проблемы используются резервные агенты вызовов, на которые происходит переключение при потери связи с действующими контроллерами шлюзов.

Реализация MGCP в Asterisk

Источник

Медиашлюз

Из Википедии — свободной энциклопедии

Медиашлюз (англ. MG, MGW или Media Gateway ) — это межсетевой шлюз, осуществляющий преобразование медиа трафика между телекоммуникационными сетями разных типов.

3GPP для IMS архитектуры определяет MGW как элемент взаимодействия IP-сети с ТфОП или беспроводными сетями 2G, 2,5G, PLMN, а для 3G эту функцию выполняет GGSN (GPRS Gateway Support Node).

Медиашлюз управляется call-агентом, в IMS функция управления принадлежит MGCF (Media Gateway Control Function), оба предусматривают управление звонками и сигнальную функциональность. В 3GPP call-агент обозначают как S-CSCF (Serving Call State Control Function). Коммуникация между медиашлюзами и call-агентами достигается с помощью протоколов, таких как MGCP и Megaco/H.248. Медиашлюз не имеет IP-интерфейсов, которые генерируют события. Каждый call-агент может контролировать ряд медиа шлюзов и потому для надежности они располагаются рядом в сети, кроме того медиа-шлюз может управляться также несколькими call-агентами поочередно (например для резервирования) или одновременно. Каждый медиашлюз должен быть физически расположен в точке взаимодействия не IP-сети, которую он поддерживает. В силу своей природы медиашлюз и его call-агенты всегда находятся рамках одного домена провайдера услуг. Медиашлюз не осуществляет взаимодействия с внешним миром через интерфейс агент контроля («Клиент») и через RTP потоки, в отличие от медиасервера.

Потоковые операции над медиа данными, такие, как подавление эха, DTMF и прочие осуществляет MRFP (процессор функции мультимедийных ресурсов) или иначе IP медиасервер в IMS согласно 3GPP, который контролируется чаще всего SIP. Медиасервер — механизм сетевой обработки общецелевого назначения выделяется отдельным элементом, так как он добавляется к любым традиционным голосовым сетям или пакетным сетям и может быть расположен в любой точке сети. В IMS контроль медиасервера осуществляет MRFC (Media Resource Function Controller), в Cable/MSO Application Manager, в NGN терминах — Application Server. В NGN (проводной и беспроводной) архитектуре, медиасервера обрабатывают медиа потоки для агентов контроля. Агенты контроля можно назвать агентами (иногда называют «гибкий коммутатор») и / или сервер приложений. Call-агент (коммутационная логика) в 3GPP IMS терминах S-CSCF, в терминах Cable/MSO как CMTS.

В сетях VoIP медиашлюз осуществляет преобразование голосового трафика, поступающего из ТфОП в RTP-пакеты и обратное преобразование.

Источник

Функции медиашлюзов (MGW). Классификация MGW. Конвертация протоколов в медиашлюзах (MGW)

Медиашлюз соединяет несколько различных сетей, его основной функцией является конвертация между различными вариантами передачи данных. Оборудование шлюзов реализует функции по преобразованию сигнальной информации сетей с коммутацией пакетов в сигнальную информацию пакетных сетей, а также функции по преобразованию информации транспортных каналов в пакеты IP/ячейки ATM и маршрутизации пакетов IP/ячеек ATM. Шлюзы функционируют на транспортном уровне NGN, хотя их можно отнести и к сетям доступа.

Медиашлюз управляется call-агентом, в IMS функция управления принадлежит MGCF(Media Gateway Control Function), оба предусматривают управление звонками и сигнальную функциональность. В 3GPP call-агент обозначают как S-CSCF (Serving Call State Control Function). Коммуникация между медиашлюзами и call-агентами достигается с помощью протоколов, таких как MGCP (Media Gateway Control Protocol), Megaco, H.248. Медиашлюз не имеет IP-интерфейсов, которые генерируют события. Каждый call-агент может контролировать ряд медиа шлюзов, для надежности они располагаются рядом в сети. Тем не менее, каждый медиашлюз может управляться только одним call-агентом и должен быть физически расположен в точке взаимодействия не IP-сети, которую он поддерживает. В силу своей природы медиашлюз и его call-агенты всегда находятся рамках одного домена провайдера услуг. Медиа шлюз не осуществляет взаимодействия с внешним миром через интерфейс агент контроля («Клиент») и через RTP потоки, в отличие от медиасервера.

Потоковые операции над медиа данными, такие как, подавление эха (см. эхоподавление), DTMF и прочие осуществляет MRFP (процессор функции мультимедийных ресурсов) или иначе IP медиасервер в IMS согласно 3GPP, который контролируется чаще всего SIP. Медиасервер — механизм сетевой обработки общецелевого назначения выделяется отдельным элементом, так как он добавляется к любым традиционным голосовым сетям или пакетным сетям и может быть расположен в любой точке сети. В IMS контроль медиасервера осуществляет MRFC (Media Resource Function Controller), в Cable/MSO Application Manager, в NGN терминах — Application Server. В NGN (проводной и беспроводной) архитектуре, медиасервера обрабатывают медиа потоки для агентов контроля. Агенты контроля можно назвать агентами (иногда называют «гибкий коммутатор») и / или сервер приложений. Call-агент (коммутационная логика) в 3GPP IMS терминах S-CSCF, в терминах Cable/MSO как CMTS.

SIP может выполнять роль конвергентного протокола контроля медиасервера, которую не могут делать MGCP или H.248.

• Trunking gateway(TG) – шлюз между ТфОП и сетью с маршрутизацией

IP-пакетов, ориентированный на подключение к телефонной сети боль-

шим количеством цифровых каналов (от десятков до нескольких тысяч).

Работает в паре с сигнальным шлюзом SG, транслирующим сигнальную

• Voice over ATM gateway (VoATM GW) – шлюз между ТфОП и АТМ-сетью,

который также подключается к телефонной сети большим количеством

цифровых каналов и представляет собой аналог Trunking Gateway;

• Residential gateway (RG) – шлюз, подключающий к IP-сети аналоговые ус-

тройства: кабельные модемы, линии xDSL и широкополосные устройства

беспроводного доступа. Обычно рассчитан на небольшое (12) количест-

• Access gateway(AG) – шлюз доступа для подключения к сети IP-комму-

никаций небольшой учрежденческой АТС через аналоговый или цифро-

вой интерфейс, или для прямого подключения аналоговых абонентских

линий, как это имеет место в мультисервисных концентраторах доступа

• Network Access Server(NAS) – сервер доступа к IP-сети для передачи данных;

• Business gateway(BG) – шлюз с цифровым интерфейсом для подключе-

ния к сети с маршрутизацией IP-пакетов учрежденческой АТС c использо-

ванием, например, системы сигнализации DSS1.

Оборудование шлюзов поддерживает протоколы:

Оборудование шлюзов поддерживает интерфейсы:

Источник

Как мы обеспечивали связь в городах Северного Полярного Круга

Северный Полярный Круг – это низкие температуры и вечная мерзлота под ногами. Климат в таких краях резко континентальный и суровый. Но здесь нужна связь. Например, в Салехарде и Лабытнанги.

Суровый зимний климат в г. Салехард

Мы провели модернизацию оборудования мобильной связи в этих городах и развернули новую опорную сеть. Был выполнен «перенос» мобильного коммутатора через реку Обь и осуществлена «телепортация» абонентов на новое оборудование. Я отвечал за организационную и техническую части этого северного проекта.

Предыстория вопроса

Салехард – это центр геологоразведочных экспедиций и одновременно город развитой рыбной промышленности. Город расположен на реке Обь и имеет свой собственный речной порт. Несмотря на свою удалённость от «большой» земли, город является региональным центром Ямало-Ненецкого Автономного Округа (ЯНАО или Ямал). Зимой температура здесь может опускаться до –40 градусов. Население Салехарда составляет 47,9 тысяч человек. Рядом с этим городом, на другом берегу реки Обь, всего в 16 км от него находится другой небольшой город Лабытнанги, численность которого составляет 26,7 тысяч человек. Порядка трети населения этих двух северных городов являются абонентами нашей компании.

Любая организация связи в регионе ЯНАО – дело непростое: среднегодовые температуры всегда отрицательные, а с конца ноября до середины февраля на значительной территории региона властвует полярная ночь. В это время года солнце ненадолго всходит над горизонтом и заходит вновь, что никак не способствует строительству новых объектов связи. Однако именно в этих местах мы затеяли не просто стройку удалённой вышки сотовой связи с базовыми станциями «на борту», а решили модернизировать опорную мобильную сеть для коммутации голосового трафика.

Работа модернизации сети получила в компании статус специального проекта. Это была стройка полноценного 3G/2G медиашлюза (что это такое – об этом чуть позже), являющегося составной частью нашей большой системы коммутации в регионе ЯНАО. К слову сказать, для обеспечения надежности наших сетей у нас в каждом региональном центре стоят отдельные системы коммутации, называемые мобильными коммутаторами. Но для Ямала необходимо было развернуть более «гибкую» систему.

Поначалу было даже не просто «разглядеть», где именно проектировалась удалённая опорная сеть: операторские технические условия в регионах у нас везде схожие и основаны на централизованном принципе масштабирования базовой архитектуры. Проблематику проектирования для Ямала мы «вкусили» немного позже, когда проект «оброс» деталями. Основная специфика, с которой мы столкнулись, была в том, что затраты на развёртывание «вынесенной» опорной сети необходимо было аккуратно и тщательно планировать, так как вопрос постоянно граничил с рентабельностью затеваемой модернизации.

Регион ЯНАО, географическое расположение Салехарда и Лабытнанги

Так сложилось исторически, что на нашем старом мобильном коммутаторе 2G, обслуживающем абонентов в Салехарде и Лабытнанги, не было возможности настраивать новые абонентские услуги, этого просто не позволяла платформа. В частности, не «поднималась» услуга мобильного переноса номера между операторами, и это была только вершина айсберга из целого ряда ограничений.

Дальше больше. Старый машзал, в котором коммутировался трафик 2G этих городов Ямала, больше не имел возможности для модернизации, и не было никаких путей для его расширения. Проблема была в том, что стойки нового 3G/2G медиашлюза и всей его современной «обвязки» больше некуда было ставить в существующем помещении. Наши мобильные сети в регионах в последние годы стали так быстро прирастать нагрузкой, а строительство базовых станций (БС), «несущих» абонентский трафик, дошло до уровня отлаженного «конвейера», что спустя всего несколько лет в таких относительно небольших городах снова требовалось расширять ёмкости сетей для пропуска голосового трафика. Более того, старый машинный зал был у нас в небольшом городе Лабытнанги, даже не в более крупном Салехарде, и по хорошему, чтобы расширяться дальше, надо было «перебираться» через реку ближе к региональному центру и создавать там новый центр мобильной коммутации. Весь персонал филиала компании, включая технический, находился в Салехарде. Необходимо было как-то разрубить этот «гордиев узел».

Для дальнейшего уточнения терминологии стоит отметить, что мобильный коммутатор операторского класса – это большой компьютер, соединяющий вызовы абонентов и управляющий всеми базовыми станциями 3G и 2G, обеспечивающими покрытие сотовой связью в регионе. Коммутатор – это «сердце» мобильной сети оператора, ключевой элемент архитектуры его «ядра» в регионе. Для 2G сетей коммутатор называется MSC (Mobile Switching Center), для 3G сетей – MSS/MGW (Mobile Soft Switсh / Media Gateway). Коммутатор 3G является универсальным сетевым узлом и позволяет одновременно обрабатывать голосовой трафик базовых станций как 3G, так и 2G. (В настоящее время коммутаторы 2G MSC выведены из эксплуатации со всех региональных сетей «ВымпелКома» от Калининграда до Камчатки и больше не используются, морально устарели.) Сам принцип работы мобильного коммутатора строится на автоматической коммутации десятков тысяч мобильных голосовых вызовов абонентов друг с другом. Это «умная» многопроцессорная машина способна оптимальным образом сжимать и пропускать голосовой трафик абонентов по каналам оператора.

Важная для нашей задачи особенность новых коммутаторов 3G/2G состояла в том, что они производятся по принципу распределенной архитектуры. Это обстоятельство позволяет максимально эффективно «заворачивать» локальный голосовой трафик абонентов в небольших городах, посредством географического «выноса» отдельного 3G/2G MGW (т.е. голосового медиашлюза), и подключения к нему локальных контроллеров управления цепочками базовых станций. По сути теперь, устанавливая медиашлюз, можно строить «кусок» мобильного коммутатора в удалённых городах ближе к абонентам, а управлять голосовым трафиком, используя «мозги» MSS на «большой земле». У абонентов, которые звонят своим друзьям и родным, за счёт «заворачивания» голосовых вызовов на месте в несколько раз снижается как время установления соединений, так и речевые задержки в ходе разговора, что ощутимо повышает качество восприятия голоса. Именно возможность реализации распределённой архитектуры новых коммутаторов позволила нам запроектировать в Салехарде установку составной части коммутатора, не нагружая большой региональный коммутатор MSS/MGW, и стыковать локальный голосовой трафик на месте.

Схема сети Лабытнанги – Салехард – Ноябрьск до модернизации

Под «большой землей» понимается, прежде всего, «ядро» и соответствующая «обвязка» большого коммутатора MSS/MGW региона ЯНАО, который находится у нас в более крупном городе Ноябрьск (и далее по тексту – это ещё и удаленная поддержка коллег из соседних региональных центров). По нашей задумке теперь между Ноябрьском и Салехардом, разнесёнными на 600 км, архитектура позволяет передавать только сигнальный обмен управления абонентским трафиком, но не сам голосовой трафик, что обеспечивает возможность экономии на аренде дорогущих транспортных каналов до северных городов Ямала за счёт сокращения потребляемой арендуемой полосы.

Возвращаясь к самому спецпроекту, следует отметить один важный факт. Нашу ситуацию с теоретическими поисками архитектуры для Ямала окончательно подтолкнуло к практике тот обстоятельство, что поставщик (он же вендор) мобильного коммутатора, обслуживающего абонентов в Салехарде и Лабытнанги, снял с производства коммутационное оборудование 2G нашего типа, и через некоторое время намеревался завершить его техподдержку. И как это обычно бывает в подобных случаях, неожиданно возросли все возможные риски, и нужно было предпринимать решительные действия. Этап планирования проекта в одночасье закончился. Дальнейшее время мы тратили уже на реализацию задуманной идеи оптимального «заворачивания» голосового трафика в местных условиях в Салехарде.

Стройка машзала и настройка оборудования

Разработав и согласовав с коллегами рабочей группы порядок взаимодействия по всем спроектированным подсистемам, мы начали подготовку к стройке. Первое, что мы сделали – это выезд в Салехарде «в поля» для сбора информации о местах возможного размещения нового машинного зала для медиашлюза.

Пересмотрев немало зданий и потратив уйму времени, мы сделали неутешительный вывод. Нам не подошло ни одно из помещений, которое могло бы быть переделано под машинный зал для оборудования операторского класса. Цена аренды мало-мальски капитальных площадок со всеми коммуникациями была для нас достаточно высока и неоправданна. Немаловажной статьёй расходов, опосредованно вложенной в цену площадки, была стоимость электроэнергии в городе с учетом двух независимых энергетических вводов и дальнейшего расширения емкостей нашего покрытия 2G и 3G (а в перспективе и 4G). И конечно сложным моментом выбора было то, что мы не могли «подтянуть» на изучавшиеся точки все наши каналы и коммуникации. Это было настоящей «засадой» ещё даже толком не начавшегося проекта.

Рассмотрев все возможные варианты, мы сошлись во мнении, что для этих северных городов проще было самим построить в «чистом поле с нуля» машзал в нужной нам точке согласно нашим операторским условиям. Легко сказать, но не так просто сделать. Ведь речь шла о вечной мерзлоте и суровой северной климатике, а «чистое поле» означало, что за основу реализации машинного зала необходимо было брать форму герметичного контейнера на земле. К нему в первую очередь, как отмечалось, должны были быть «подтянуты» два независимых энергетических ввода, и во вторую – «прокинуты» дублированные транспортные каналы связи по воздушным радиорелейным линиям (РРЛ). По-существу, для локального 3G/2G медиашлюза MGW, оставалось строить собственный, прорезервированный во всех смыслах «дом», оснастив его рабочими местами операторов.

Подготовив на чертеже будущего машзала все необходимые стойки оборудования с учётом расширения, мы определили соответствующие размеры контейнера и выбрали место, начав стройку своими силами. Строительные работы на площадке были логически разделены на 2 этапа. Этап 1 – строительство основного контейнера, оснащение его системами «жизнеобеспечения» для машинного зала, подключение системы видеонаблюдения, одновременно с этим строительство трансформаторной подстанции в отдельном контейнере. Этап 2 – установка и монтаж телеком-оборудования опорной сети 3G/2G, пуско-наладка и интеграция MGW, состыковка его с «ядром» большого коммутатора MSS/MGW Ноябрьска, а также со старым коммутатором в Лабытнанги, мультивендорное тестирование всех подсистем со всеми, проверка мобильных сервисов, и подготовка всей системы к опытно-коммерческой эксплуатации.

Выбор строительных компаний-подрядчиков для наших «хотелок» был осуществлён через конкурс. Вечная мерзлота – дело не шуточное. Затем, совместно с подрядчиками, весной мы отправили заказ на изготовление контейнера на один из заводов металлоконструкций на Урале и начали дожидаться окончания производства. Его внушительные габариты и вес были не типовым для стандартно предлагавшихся боксов для базовых станций, поэтому изготовление выполнялось «на заказ».

Забивка свай и подготовка фундамента для контейнера

После томительного ожидания контейнер был получен с завода и доставлен на место. Тут же началась сборка нашего «дома». В целом можно сказать, что строительство аппаратных боксов в условиях севера – это дело ответственное и очень трудоёмкое. И наш контейнер для нового 3G/2G медиашлюза возводился в соответствии со всеми технологическими этапами строительства аппаратных боксов для этих краёв. Каких-либо непреодолимых сложностей, например с грунтами, мы не испытали в этой части проекта, стройка «дома» завершилась без форс-мажоров.

Контейнер машзала получился надёжный, с усиленной тепловой и гидроизоляцией. В нём были установлены кондиционеры и система обогрева воздуха, работающие в автоматическом режиме. Рабочая температура в контейнере постоянно поддерживается около 22х градусов, работает полный климат-контроль. Присутствуют датчики пожара, затопления и полный комплекс мониторинга, который позволяет обнаруживать случаи неполадок. Кроме того, на площадке в отдельном контейнере была собрана собственная трансформаторная подстанция с необходимыми распределительными устройствами.

Подключенные распределительные устройства трансформаторной подстанции

По результатам 1го строительного этапа с небольшим символическим «новосельем» мы запустили контейнер машзала в эксплуатацию, и на площадке уже можно было «жить». Дальше нужно было ускоряться со 2м этапом, так как нас начали поджимать холода.

Одновременно с работами по изготовлению контейнера было закуплено всё необходимое телеком-оборудование 3G/2G для опорной сети, и оно уже ждало нас на региональном складе. Но затянувшиеся сроки изготовления и доставки нашего «дома» с завода, а также сборки его подрядчиками, и кроме того – запуск на площадке собственной трансформаторной подстанции, сдвинули сроки готовности 1го этапа проекта на позднюю осень. Короткие лето и осень закончились, на Северном Полярном Круге пошли снега, и важно было «нагонять» выполнение 2го этапа: завоз и тесты купленного коммутационного оборудования.

Наш опыт работы с северами вёл нас к тому, что отправку операторского оборудования железной дорогой со склада, который находится у нас в Тюмени, нужно было делать как минимум за месяц, а лучше ещё раньше. Железнодорожный состав со стойками мог доехать до нашего места на Северном Полярном Круге только через Сыктывкар, пройдя заодно в обход ещё 4 региона, и дойдя лишь до ЖД станции в Лабытнанги. Дальше путей не было никаких, а впереди дорогу к нашей площадке преграждала река Обь. Железной дороги из Лабытнанги в Салехард пока не существует, мостов тоже. Учитывая это обстоятельство, мы постарались больше чем за месяц отправить оборудование транспортной компанией до Лабытнанги, по прибытию оперативно сгрузить его с железной дороги, и направиться к парому через реку. Знать бы тогда, что планируя логистику на «большой» земле настолько заранее, нас очень сильно в итоге подведёт ухудшающийся прогноз погоды.

Нам не хватило всего 5 часов последнего дня этого маршрута, чтобы переправить паромом все наши многочисленные ящики и коробки. К слову, переправляться через реку людям возможность-то была, в межсезонье ходит катер на воздушной подушке, подобно городской маршрутке, а вот для грузового транспорта дороги через реку больше не существовало. Река разом «отрезала» все возможные попытки попасть на удалённую площадку.

Зимняя переправа Салехард–Лабытнанги через реку Обь

Так иногда бывает. Мы набивали нашу «посылку» обоим северным городам всем необходимым «железом» и даже с запасом, целый месяц везли её по железной дороге, так как авиапочтой такой груз было не отправить, и не успели совсем чуть-чуть. И больше ничего не оставалось, как три недели ждать «у моря погоды», пока через реку Обь снова не откроется безопасная дорога для прохода грузового транспорта, но теперь уже по зимнему льду, называемому «зимником». Но пережили и это. Однако кто бы мог подумать тогда, что впоследствии именно эта цепочка сдвига сроков и приход на север затяжных отрицательных температур только помогут нам с полноценным запуском нового 3G/2G медиашлюза в эксплуатацию в суровых климатических условиях.

Как только в машзал были доставлены все необходимые коробки с телекомовским «железом», на площадку последовательно были «заброшены» авиарейсами представители вендоров нового оборудования, и работа «закипела» в ускоренном темпе. Инженеры были оповещены о работах заранее, и в назначенные дни и часы они прилетали к нам в Салехард один за другим, не мешая, и не задерживая друг друга, дожидаясь своих сроков интеграции, что было очень ценно. Совместно с нашими техническими коллегами вендоры и их подрядчики состыковывали различные подсистемы опорной сети между собой, обменивались опытом, тестировали и перетестировали, и вскоре работа набрала нужный темп. Система начала срастаться «на глазах».

Монтаж телеком-оборудования в новом машзале

Тестирование нового 3G/2G медиашлюза MGW производили на двух тестовых базовых станциях 3G и 2G, собранных здесь же, в контейнере, но подключенных к тестовым антеннам через аттенюаторы. Сконфигурировав нужные пороги уровней сигналов базовых станций, мы уверенно прошли все настроечные тесты мобильных переходов 3G-2G-3G на тестовых смартфонах. Аналогично были выполнены все сигнальные тесты MSS–MGW между городами, затем тесты мобильных сервисов. В итоге в машзале «поднялись» все необходимые сетевые элементы опорной сети и систем управления трафиком. И естественно, были также проверены и введены в эксплуатацию резервные аккумуляторные батареи. Наш 2й строительный этап на площадке плавно подошёл к концу и протестированная опорная сеть наконец-то была готова к приёму трафика.

Резервирование энергетики аккумуляторными батареями

Здесь стоит отметить, что специфика управления проектом на Ямале была в том, что в этих северных городах нам постоянно не хватало технических специалистов. Приходилось искать в компании инженеров из соседних регионов, специализирующихся на аналогичных мобильных подсистемах, и просить коллег командироваться на север в помощь вендорам и местным техническим коллегам для оптимальной настройки «железа» под единые требования сетей большой компании. Ведь местные коллеги в Салехарде были не настройщиками нового «железа», хотя в процессе совместной настройки коммутационной сети они стали настоящими «многостаночниками», специализирующимися на оборудовании самых различных подсистем. В итоге проект выкатился на «финишную прямую», и впереди нас ждал перенос «живого» абонентского трафика.

Перенос абонентского трафика

Дальше предстояло переносить абонентский трафик всех базовых станций двух удалённых городов Ямала на новый, только что отстроенный 3G/2G медиашлюз MGW. Часы самого ответственного момента этого спецпроекта стремительно приближались. Как рассказывалось ранее, подготовка переноса коммерческого мобильного трафика заключалась в том, что в проекте на новой площадке сначала был «поднят» дубль коммутационного оборудования до «горячего резерва», и только потом открывался путь для выполнения переключения голосового трафика абонентов с возможностью «отката» к старой конфигурации на случай проблем. Теперь в двух машзалах по обе стороны реки Обь для этого всё было готово.

Элементы отстроенной системы (слева направо): кондиционер, медиашлюз MGW, контроллер базовых станций 3G

Как образно заметил один из наших коллег, участвовавший в проекте, перенос абонентского трафика напоминал пересадку коммерческих пассажиров из старого самолёта в современный лайнер. Представьте на минуту, что вы член экипажа пассажирского самолета, выполняющего перелет через Атлантику. От вас требуется прямо в полете оперативно пересадить всех пассажиров на новый надёжный лайнер, летящий рядом параллельным курсом. Но пассажирам об этом знать ни к чему: они летят по своим делам, отдыхают за газетой, или крепко спят, полёт проходит нормально. Не слишком реальная задача, не правда ли? С нашей мобильной сетью в двух удалённых городах Ямала нужно было сделать тоже самое.

Невозможно остановить эксплуатацию телефонной сети в «полёте», подготовить телеком-оборудование, наладить его, и потом благополучно продолжить «полёт» в модернизированных условиях. В сжатые сроки нам нужно было не только безболезненно для абонентов перенести всю радиочасть из цепочек базовых станций, управляя процессом удалённо за 600 км из Ноябрьска с поддержкой из региональных центров. Нам нужно было сохранить всё то, что было уже накоплено для абонентов северных городов за годы существования сети 2G: подключения SMS- и MMS-центров, стыки с многочисленными сервисными платформами, соединения с другими мобильными и фиксированными операторами, мини-АТС, и многое-многое другое. В процессе переноса мобильного трафика не должно возникнуть ни малейшего влияния на сеть и услуги, «просадка» качества тут не допустима.

Для выполнения этого этапа проекта требовалось провести существенную документальную проработку: что, зачем, и в какой последовательности переключается, как пойдут транспортные потоки, как нагрузятся новые сетевые элементы, и т.д. Само конфигурирование и переключение мобильного трафика выполняется в один день глубокой ночью при минимальной сетевой нагрузке. Но это если всё пойдёт по плану.

Во время отладки переноса трафика между коммутаторами в Лабытнанги и Салехарде, определённую сложность у нас вызывала одновременная «стыковочная» работа в машзалах по обе стороны реки Обь. Нам приходилось ещё не раз переправляться через реку на зимнем катере или на легковой машине и «подтягивать» на новую площадку какое-нибудь расширяющее ёмкости «железо», различные блоки для сетей 3G и 2G, модули, платы, кабели, коннекторы, и прочее-прочее-прочее. Сам перенос мобильного трафика со старого в новый машзал предстояло выполнять по воздушным радиорелейным линиям.

Антенны радиорелейных систем, основной и резервный каналы

Для начала мы решили проверить готовность транспортной сети к переносу и подать на новую площадку по релейкам небольшой транзитный трафик, с тем, чтобы в опытно-коммерческом режиме понаблюдать за ошибками в каналах. Что-то подсказывало, что нагрузку полноценным абонентским трафиком подавать ещё было рано, это нужно было делать постепенно. И по результатам пробного включения картина сложилась действительно не радужная. Уровень сигнала релеек на новой площадке апериодически «плавал», параметры радиоканалов сами собой то ухудшались, то улучшались, приводя к частичному «залипанию» линий. Полноценное переключение трафика было отложено до выяснения причин с релейным «транспортом».

Как обнаружилось позже, причиной «плавающего» эффекта в радиоканалах было то, что у нас частично отмерзало новое радиорелейное оборудование, установленное на крыше нашего контейнера. Мы не планировали делать настройки мобильной сети зимой в суровых климатических условиях, скорее наоборот, но, как отмечалось ранее, стройка затянулась и вот сама природа теперь «подсказала» нам, что до запуска системы в эксплуатацию новые релейки надо менять на более надёжные. Вскоре, после замены релеек, связь с новым машинным залом настроилась устойчивая.

Построенная площадка: слева – контейнер трансформаторной подстанции, справа — контейнер нового машзала

Наконец настал час «Х» этого северного «приключения». На ночные работы вышли коллеги в разных городах нашей компании, чтобы удалённо на различных подсистемах управления 3G и 2G поддержать север своим участием. Глубокой ночью, когда оба города погрузились в сон, на двух разнесённых площадках в Салехарде и Лабытнанги для переноса трафика были открыты все необходимые транспортные каналы. Старый и новый коммутатор были «состыкованы».

На новый медиашлюз, в штатном режиме и без лишней суеты, один за другим начали «телепортироваться» абоненты со старого коммутатора. Опорная сеть 3G/2G «приняла» сначала сотни, а затем тысячи голосовых звонков абонентов северных городов Ямала и начала их коммутацию, светясь на платах нового машинного зала яркой светодиодной индикацией. «Откатов» на исходную конфигурацию в ту ночь не случилось, и на площадку была успешно «занесена» и культивирована новая «жизнь». Никаких фатальных сбоев оборудования под нагрузкой не было. К утру конфигурирование и перевод трафика на всех подсистемах были успешно завершены, и старый мобильный коммутатор был «освобожден» от внутреннего абонентского трафика.

Весь следующий день до «ночной» смены наших коллег с передовой этих «боевых» действий было невозможно дозвониться с поздравлениями, многих пришлось разыскивать уже позже. Все куда-то разом пропали и наповал выключили мобильные телефоны, уйдя в глубокий сон. Это был хороший знак. Работа с самым напряжённым участком проекта, переносом внутреннего трафика абонентов на новое «железо», была закончена, и продублированные транспортные каналы в Салехарде нас не подвели. Теперь можно было спокойно нагружать вынесенный 3G/2G медиашлюз MGW оставшимся трафиком.

Немного отойдя от артподготовки переноса внутреннего трафика и не откладывая в долгий ящик, следующим заходом мы реализовали перенос внешнего мобильного трафика – так называемый трафик «стыковочных» каналов присоединений с другими операторами. Это необходимо было делать, чтобы наши абоненты в Салехарде и Лабытнанги теперь могли свободно звонить региональным абонентам других операторов связи через тот же новый медиашлюз. Для этого с каждым местным оператором телефонной связи были предварительно согласованы технические условия «состыковки» и пройдены тесты коммутации звонков. После этого наш новый 3G/2G медиашлюз MGW был «привязан» к коммутаторам других операторов региона ЯНАО. Аналогичным образом, через тесты и мониторинг, на новое «железо» был перенесён весь оставшийся технический трафик.

Исход этой истории был закономерен и логичен. Мы не отказались от старого машзала, а преобразовали его. После снятия всей абонентской нагрузки старый мобильный коммутатор был «заглушен», его техподдержка благополучно завершилась, а устаревшее «железо» было демонтировано на склад, расчистив место для новых стоек под расширение покрытия сети доступа. Тем самым, «замыкая круг», на старой площадке был реализован очередной виток модернизации оборудования из череды наших постоянных технических работ по оптимизации сети.

Итоги

В результате проделанных работ и строительства 3G/2G медиашлюза MGW была реализована распределённая архитектура опорной сети в регионе ЯНАО. Мы вынесли медиашлюз ближе к удаленным абонентам и «завернули» локальный голосовой трафик на месте, тем самым сократив жителям северных городов время установления соединений и задержки передачи голоса. На границах сетей доступа 3G и 2G также были сокращены срывы голосовых вызовов, так как теперь все звонки обрабатываются на едином 3G/2G медиашлюзе MGW, «заточенном» на работу в двух стандартах.

Всё построенное в новом машзале оборудование было передано «на сохранение» местным техническим коллегам и оно настроено на работу в автоматическом режиме. В случае возникновения проблем всё оборудование поддерживает режимы удалённого конфигурирования с «большой» земли. И на месте всегда рядом есть коллеги, которые мониторят различные нештатные ситуации. Если что-то не так, то коллеги способны своими силами «передёрнуть» кабели и платы.

Модернизированная опорная сеть 3G/2G на новом медиашлюзе оптимально отработала пиковые Новогодние нагрузки звонков в Салехарде и в Лабытнанги. Сеть работала без сбоев и не ушла в «недозвон» от перегрузок, а абоненты без проблем смогли поздравить друг друга с Новым Годом. Это было ценно.

Случившиеся в начале этой зимы морозы под –40 градусов, и продолжившиеся после Нового Года, не оказали никакого влияния на опорную мобильную сеть в Салехарде. Транспортное оборудование, энергетика и все системы на площадке работали штатно. И наши абоненты северных городов чувствовали себя уверенно.

В заключении хотелось бы поблагодарить всех коллег, принимавших участие в разработке, проектировании и реализации этого северного проекта: Сургутский, Тюменский, Челябинский филиалы, управление Уральского региона «ВымпелКома», вендоров и подрядчиков. Вся рабочая группа проекта работала достаточно синхронно, подобно единому живому организму. Объём выполненных работ стал для нас в чём-то собственным «покорением» широт Северного Полярного Круга. И это был действительно незабываемый опыт.

Источник

Обучение и знания

mgw что это такое

Media Gateway