Программное обеспечение коммутационных узлов и станций

Приведенный в эпиграфе ответ Евклида справедлив по отноше­нию не только к геометрии, но и к программному обеспечению (ПО) узлов коммутации, изучение которого требует сложных и глубоких курсов гораздо большего объема, чем может вместить одна глава учебника. Ктомуже, на ПО приходится более 80% стоимости разра­ботки современной АТС, и оно практически полностью определяет ее функциональные возможности. Вот почему эта глава оказалась для автора самой сложной с точки зрения того, как ее построить. В результате получилась такая структура: следующий параграф по­священ аппаратной поддержке ПО узла коммутации и анализу раз­ных вариантов ее архитектуры; далее рассмотрены основы програм­мирования задач обслуживания вызовов в реальном времени, эле­менты алгоритмического обеспечения на языках SDL и MSC и каче­ственные характеристики ПО.

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

Самый нижний уровень ПО обычно встраивается в абонентские и линейные комплекты и другие модули станции. Программные сред­ства на этом уровне, как правило, зависимы от аппаратных средств и в англоязычной литературе называются middleware, что подчеркивает их промежуточное положение между аппаратными средствами hardware и основным программным обеспечением software. Реали­зуемые здесь функции связаны, в основном, с контроллерами ли­нейных и станционных интерфейсов и с поддержкой нижнего уров­ня обработки вызова. Например, когда абонент поднимает трубку, первый уровень управления абонентским модулем детектирует со­стояние снятия трубки (off hook) и запрашивает у контроллера вто­рого уровня информацию о данной абонентской линии, классе ее обслуживания, возможностях абонентского терминала, каких-либо ограничениях. Затем первый уровень обеспечивает посылку абонен­ту сигнала ответа станции. После набора номера накопленные пер­вым уровнем цифры передаются выше.

Второй уровень управления обычно реализуют процессоры управления коммутацией с распределенными функциями, взаимо­действующие друг с другом через коммутационное поле или через общую шину. Для межпроцессорных связей используют разнообраз­ные протоколы, причем в большинстве цифровых АТС применяются модификации стандартных протоколов ОКС7 или Х.25. Основные процессоры управления коммутационным полем для надежности дублируются. На этом уровне анализируются набранные абонентом цифры и выбирается путь через коммутационное поле. После того как соединение установлено, второй уровень управления поддер­живает его и разрушает, как только обслуживание вызова переходит в фазу разъединения..

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

Управляющие устройства

Описанию различных вариантов организации устройств про­граммного управления коммутацией в недавнем прошлом было по­священо немало публикаций, объем которых постепенно уменьшал­ся по мере качественного изменения самих этих устройств в полном соответствии с законом Мура. Описываемое этим законом сниже­ние стоимости микропроцессорных управляющих устройств одно­временно с радикальным увеличением их производительности по­гасило былые споры между сторонниками централизованной и распределенной архитектур программного управления и привело к тому, что в большинстве современных цифровых АТС используется архи­тектура, представляющая собой что-то среднее между двумя назван­ными подходами. Сегодняшние варианты архитектуры управления цифровой коммутацией можно разделить на три типа: централизо­ванное управление, иерархическое управление и распределенное управление.

Централизованное управление

Архитектура централизованного управления условно изображе­на на рис. 9.1. Эта архитектура восходит к началу сорокалетней ис­тории развития электронных узлов коммутации, управляемых ЭВМ, которая началась в ноябре 1960 года в г. Морис (штат Иллинойс, США) испытаниями прототипа электронной АТС. В 1965 году в г. Сак-касана (Нью-Джерси, США) была сдана в эксплуатацию серийная электронная система коммутации ESS-1 с управлением по записан­ной программе, базирующаяся исключительно на центральном про­цессоре, который управляет всеми функциями системы. Отечест­венный ИВТУ, рассмотренный в главе 6, полностью соответствует структуре, показанной на рис. 9.1.

Рис. 9.1 Структура АТС с централизованным программным управлением

Централизованное программное управление этих АТС предусмат­ривает выполнение следующих трех групп функций:

• управление обслуживанием вызова, включая анализ имеющейся в базе данных информации, относящейся к вызываемому абонен­ту, прием набираемого номера, контроль процесса обслужива­ния вызова во всех фазах этого процесса, включая фазы отбоя и разъединения; управление коммутацией, для чего в зависимости от структуры АТС используются разные методы, но в любом случае центральный процессор хранит отображение всех путей (и свободных, и используемых), находит и резервирует путь для запрашиваемого абонентским или линейным модулем соединения;

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

Иерархическое управление

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

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

Распределенная архитектура

Концепция распределенного программного управления появи­лась еще в 60-х годах прошлого века и была воплощена в цифровой системе коммутации ЕЮ (Франция). Она предусматривала разбие­ние множества задач управления на несколько составных частей по принципу разделения функций (function sharing) и/или разделения нагрузки (load sharing). Концептуально полностью распределенная архитектура соответствует архитектуре управления в Системе 12 или в АТСЦ-90, которые были рассмотрены, соответственно, в главах 6 и 5. Ее можно также определить как архитектуру без центрального процессора (central-processor-less).

Все функции управления разделяются на специализированные наборы задач, содержащиеся в независимых процессорах и обес­печивающие в совокупности выполнение всех связанных с управле­нием операций. К примеру, процессор абонентской ступени перио­дически (с интервалом порядка 10 мсек) сканирует абонентские ли­нии, включенные в эту ступень, отслеживает все возникающие в нем вызовы, поддерживает базу данных абонентов, ведет наблюдение за каждым вызовом и даже проводит локальное восстановление и ло­кальную диагностику своей схемы. Все процессоры общаются друг с другом путем обмена сообщениями через коммутационное поле, общую шину или иным способом - и это является основой конструк­ции системы программного управления узлом коммутации. Что же касается задачи обеспечить работу всех этих процессов в реальном времени, то даже с приходом гораздо более быстродействующих процессоров, усовершенствованных протоколов обмена сообще­ниями и улучшенных архитектурных средств актуальность этой про­блематики не становится меньшей, о чем будет идти речь в следую­щем параграфе - да и не только в нем.