Способ и устройство для конфигурирования данных

Способ и устройство для конфигурирования данных

Иллюстрации

Показать все

Реферат

Настоящая заявка претендует на приоритет Заявки на патент Китая № 201010042718.9, поданной в Патентное ведомство Китая 8 января 2010, озаглавленной «СПОСОБ И УСТРОЙСТВО ДЛЯ КОНФИГУРИРОВАНИЯ ДАННЫХ» и включенной сюда во всей полноте посредством ссылки.

Область техники, к которой относится изобретение

Настоящее изобретение относится к области технологий связи и в частности к способу и устройству для конфигурирования данных.

Предпосылки к созданию изобретения

В сети связи всю совокупность режимов управления сетью можно разделить на две группы в зависимости от сложности сетей: режимы первой группы применяют, когда сетевых элементов относительно мало и эти элементы почти однотипны, так что оператор сети связи может управлять сетевыми элементами посредством только одной системы управления элементами (element management system, (EMS)); режимы второй группы применяют, когда число сетевых элементов велико или типы этих сетевых элементов весьма разнообразны, так что оператору сети связи нужны несколько систем EMS для управления этими сетевыми элементами в группах, причем этими несколькими EMS можно управлять посредством системы управления сетью (Network Management System, (NMS)). Эта система NMS преимущественно реализует уровень управления сетью (Network Management Layer, (NML)) в сети управления телекоммуникациями согласно стандарту Международного союза электросвязи (ITU TMN) и выполняет функцию управления работой, ориентированную на сетевое устройство. Система EMS преимущественно выполняет функцию уровня управления элементами (Element Management Layer, EML) в системе по стандарту ITU TMN, иными словами, выполняет функцию управления работой, ориентированную на устройство. Интерфейс между системой NMS и системой EMS именуется интерфейсом к вышестоящей системе (Interface-N, Itf-N). С точки зрения интерфейса Itf-N система NMS обычно именуется Менеджер, а система EMS обычно именуется Агент, так что Агент взаимодействует с Менеджером через интерфейс Itf-N. На сегодняшний день многие операторы сетей связи применяют режим совместного управления Менеджером и Агентом.

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

Краткое изложение существа изобретения

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

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

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

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

Один из вариантов настоящего изобретения далее предлагает способ конфигурирования данных, содержащий:

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

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

Один из вариантов настоящего изобретения предлагает устройство конфигурирования данных, включающее:

модуль настройки, конфигурированный для установления способа конфигурирования данных в виде способа самоконфигурирования данных или традиционного способа конфигурирования данных;

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

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

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

Краткое описание чертежей

Фиг. 1 представляет логическую схему первого варианта способа согласно настоящему изобретению;

Фиг. 2 представляет логическую схему второго варианта способа согласно настоящему изобретению;

Фиг. 3 представляет логическую схему третьего варианта способа согласно настоящему изобретению;

Фиг. 4 представляет логическую схему четвертого варианта способа согласно настоящему изобретению;

Фиг. 5 представляет логическую схему пятого варианта способа согласно настоящему изобретению;

Фиг. 6 представляет логическую схему шестого варианта способа согласно настоящему изобретению;

Фиг. 7 представляет логическую схему седьмого варианта способа согласно настоящему изобретению; и

Фиг. 8 представляет структурную схему варианта устройства согласно настоящему изобретению.

Подробное описание вариантов изобретения

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

Как показано на Фиг. 1, первый вариант способа согласно настоящему изобретению включает следующие этапы:

Этап 102: Прежде получения сетевым элементом доступа в сеть модуль управления обращается к первому интерфейсу между модулем управления и управляемым модулем, чтобы передать управляемому модулю команду загрузить данные конфигурации сетевого элемента из пункта, назначенного модулем управления.

Указанный выше пункт, назначенный модулем управления, может представлять собой физическое устройство, где расположен этот модуль управления, или сервер третьей стороны.

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

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

В некоторых вариантах перед этапом 104 может быть дополнительно включен следующий этап:

Этап 103: Модуль управления обращается к третьему интерфейсу между этим модулем управления и управляемым модулем, чтобы передать управляемому модулю команду проверить данные конфигурации.

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

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

Поскольку первый интерфейс, второй интерфейс или третий интерфейс, упомянутые выше, могут быть вновь определяемыми интерфейсами, а также могут быть интерфейсами, полученными в результате внесения изменений в известный интерфейс в процедуре BulkCM (bulk configuration management (управление массовой конфигурацией)), эти интерфейсы введены в описанных далее вариантах.

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

(1) Интерфейс startSession: Обращаясь к этому интерфейсу, Менеджер открывает сеанс и инициализирует временные ресурсы, относящиеся к этому сеансу, у Агента.

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

входной параметр: sessionId, этот параметр используется для идентификации нового сеанса;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: указанный выше идентификатор sessionId в настоящий момент не используется.

(2) Интерфейс endSession: Обращаюсь к этому интерфейсу, Менеджер завершает сеанс, стирает файлы (такие как временный файл и файл журнала сеанса), связанные с сеансом, у Агента, и освобождает соответствующие ресурсы в системе. Если до этого было обращение к «предварительно активизированному» интерфейсу, Менеджер обращается к интерфейсу endSession, чтобы завершить сеанс и освободить все внутренние локальные ресурсы, которые были назначены этому «предварительно активизированному» интерфейс). Если сеанс находится в состоянии выполнения, таком как загрузка, скачивание или активизации, Менеджер отказывается обращаться к интерфейсу, чтобы завершить сеанс.

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

входной параметр: sessionId, этот параметр используется для идентификации нового сеанса;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: указанный выше идентификатор sessionId в настоящий момент не используется.

(3) Интерфейс скачивания: Обращаясь к этому интерфейсу, Менеджер передает Агенту команду скачать файл, содержащий данные конфигурации, и управлять этим файлом. Агент может получить файл данных конфигурации по назначенной ссылке на глобально уникальный файл данных.

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

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

входной параметр: sessionId, этот параметр используется для идентификации сеанса, относящегося к скачиванию файла данных конфигурации; и downloadDataFileReference, этот параметр используется для определения ссылки на глобально уникальный файл данных, соответствующий данным, которые нужно скачать, причем эта ссылка на глобально уникальный файл данных обычно представляет собой адрес, где хранится конкретный файл;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: сеанс, идентифицированный посредством параметра sessionId, успешно открыт и находится в состоянии «не занято» (IDLE).

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

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

входной параметр: sessionId, этот параметр используется для идентификации сеанса, относящегося к скачиванию файла данных конфигурации;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: Агент успешно открыл сеанс, идентифицированный параметром sessionId, и либо уже выполнил операцию «скачивания», либо выполняет такую операцию «скачивания» повторно.

(5) Интерфейс generateFile: Обращаясь к этому интерфейсу, Менеджер передает Агенту команду создать файл полных данных конфигурации.

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

входной параметр: sessionId, этот параметр используется для идентификации сеанса, относящегося к скачиванию файла данных конфигурации;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: Агент успешно открыл сеанс, идентифицированный параметром sessionId, и завершил проверку скачиваемых данных.

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

Этап 201: Прежде получения сетевым элементом доступа в сеть, Менеджер сначала обращается к интерфейсу startSession, чтобы открыть сеанс; если сеанс находится в состоянии «не занято» (IDLE), выполните этап 202; если сеанс находится не в состоянии «не занято» (IDLE), выполните этап 205.

Этап 202: Менеджер обращается к интерфейсу скачивания, чтобы передать Агенту команду скачать файл, содержащий данные конфигурации, и управлять этим файлом; если скачивание завершено, выполните этап 203; если скачивание осуществить не удалось, выполните этап 205.

Этап 203: Менеджер обращается к контрольному интерфейсу, чтобы передать Агенту команду проверить данные конфигурации, скачанные перед этим; если проверка завершена, выполните этап 204; если проверку осуществить не удалось, выполните этап 205.

Указанный выше этап 203 является опцией, так что после завершения скачивания на этапе 202, можно сразу перейти к выполнению этапа 204.

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

Этап 205: Менеджер обращается к интерфейсу endSession, чтобы завершить указанный выше сеанс и передать Агенту команду стереть файл, относящийся к этому сеансу, и освободить соответствующие ресурсы для системы.

Указанный выше файл, относящийся к сеансу, включает временный файл, файл журнала сеанса и т.п.

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

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

скачивание не удалось (Download Failed)

скачивание завершено (Download Completed)

проверить не удалось (Validation Failed)

проверка завершена (Validation Completed)

файл конфигурации создать не удалось (generateFile Failed)

файл конфигурации создан (generateFile Completed)

Например, после того, как Менеджер обратился к интерфейсу скачивания, Агент может известить Менеджера по обратной связи, что скачивание данных завершено или скачать данные не удалось, посредством сообщения notifySessionStateChanged. Если скачивание данных завершено, сообщение notifySessionStateChanged содержит информацию «скачивание завершено» (Download Completed). Если скачать данные не удалось, сообщение notifySessionStateChanged содержит информацию «скачивание не удалось» (Download Failed). После обращения к контрольному интерфейсу или интерфейсу generateFile, Агент может по обратной связи известить Менеджера о состоянии данных конфигурации посредством сообщения notifySessionStateChanged аналогичным образом, поэтому соответствующие примеры здесь не приведены.

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

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

входной параметр: sessionId, это параметр, используемый для идентификации назначенного сеанса; и logFileReference, это параметр, используемый для определения адреса и имени файла для записи результатов у Менеджера;

выходной параметр: результат операции (успешно или неуспешно); и

предварительное условие: сеанс, идентифицированный посредством параметра sessionId, успешно открыт, и это сеанс еще не завершен.

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

Перед введением указанного варианта настоящего изобретения необходимо кратко рассмотреть существующую процедуру BulkCM для лучшего понимания читателями.

Процедуру BulkCM применяют к загрузке (Upload) и скачиванию (download) данных конфигурации интерфейса к вышестоящей системе, а обработка данных для полного конечного автомата, механизма оповещения и журнала сеанса (SessionLog) определена в стандарт. Однако эта процедура относится главным образом к сценарию ежедневного обслуживания, иными словами, к ситуации, когда развертывание сетевого элемента завершено, и к сценарию, когда развертывание сетевого элемента невозможно поддержать правильно. Поскольку предварительным условием обращения к интерфейсу Активизации (Activate) в процедуре BulkCM является то, что сетевой элемент обязательно должен быть онлайн; обращение к интерфейсу в противном случае будет неудачным; а в ситуации реального развертывания, в фазе подготовки данных, очень велика вероятность, что сетевой элемент не завершил инсталлирование оборудования, вследствие чего обращение к интерфейсу Активизации может быть неудачным. Для завершения развертывания посредством непосредственного применения существующей процедуры BulkCM автор настоящего изобретения рассматривал в процессе исследований два следующих решения:

(1) Перед инсталлированием оборудования Менеджер обращается к интерфейсу StartSession, чтобы начать сеанс, затем обращается к интерфейсу скачивания и контрольному интерфейсу для завершения передачи и проверки данных конфигурации and и, наконец, обращается к интерфейсу активизации после того, как сетевой элемент перейдет в режим онлайн.

(2) Менеджер заранее готовит данные конфигурации для сетевого элемента, но пока не запускает программу BulkCM; после завершения инсталлирования сетевого элемента и получения доступа к Агенту происходит обращение к программе BulkCM для передачи данных конфигурации сетевому элементу.

Указанное выше первое решение не создает проблем, когда сетевой элемент находится в режиме онлайн, однако не подходит, если сетевой элемент перешел в режим онлайн после относительно продолжительной задержки. Поскольку после обращения к интерфейсу startSession из совокупности интерфейсов к вышестоящей системе, чтобы начать сеанс, этот сеанс невозможно прервать прежде, чем сетевой элемент получит доступ в сеть, то, при всей ограниченности ресурсов для сеансов, рассматриваемый способ занимает ограниченные ресурсы системы в течение продолжительного времени.

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

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

Для разъяснения читателям, какие именно интерфейсы процедуры BulkCM пересмотрены в вариантах настоящего изобретения, ниже будет приведено подробное сравнение определения исходного интерфейса с определением пересмотренного нового интерфейса в процедуре BulkCM.

В процедуре BulkCM определены преимущественно следующие интерфейсы:

(1) Интерфейс скачивания (download)

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

Определение нового интерфейса: такое же, как определение исходного интерфейса.

(2) Контрольный интерфейс (validate)

Определение исходного интерфейса: Обращение к этому интерфейсу является опцией, так что, обращаясь к этому интерфейсу, Менеджер передает Агенту команду проверить данные конфигурации, скачанные перед этим. Для обращения к этому интерфейсу Менеджер может обратиться к предварительно активизированному интерфейсу или активизированному интерфейсу, чтобы передать Агенту команду проверить ошибки в данных конфигурации, скачанных перед этим, и затем выполнить предварительную активизацию или «активизацию» в соответствии с этими данными конфигурации. Интерфейс включает в качестве опции параметр "activationMode", указывающий способ активизации.

Определение нового интерфейса: Менеджер обращается к этому интерфейсу, чтобы передать Агенту команду проверить скачанные данные конфигурации; а но сравнению с традиционным интерфейсом новый интерфейс не нуждается в параметре "activationMode" (поскольку реальная активизация данных конфигурации па стороне сетевого интерфейса не связана с этим параметром в рамках нового сценария развертывания, нет нужды задавать режим активизации).

(3) Интерфейс активизации (activate)

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

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

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

Как показано на Фиг. 3, третий вариант настоящего изобретения предлагает способ получения данных, реализованный в виде совокупности следующих этапов:

Этап 301: Менеджер обращается к интерфейсу Скачивания, чтобы передать Агенту команду скачать файл, содержащий данные конфигурации, из пункта, назначенного Менеджером.

Этап 302: Менеджер обращается к пересмотренному Контрольному интерфейсу, чтобы передать Агенту команду проверить скачанные данные конфигурации для определения их приемлемости.

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

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

В некоторых вариантах после этапа 303 может быть, в качестве опции, включен следующий этап:

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

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

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

Чтобы варианты настоящего изобретения были совместимы с применением традиционной процедуры BulkCM в сценарии обслуживания, согласно четвертому варианту настоящего изобретения в файл конфигурации, передаваемый Менеджером Агенту, могут быть внесены некоторые изменения, например, в узел bulkCmConfigDataFile этого файла конфигурации, передаваемого Менеджером Агенту, может быть добавлен атрибут scenarioType, используемый для индикации способа конфигурирования данных. Ниже рассмотрен способ добавления этого атрибута:

После генерации указанного выше файла конфигурации и передачи его Менеджером Агенту этот Агент должен настроить у себя логические операции, которые должен выполнять каждый интерфейс, например, если указанный выше атрибут scenarioType имеет значение «традиционный» (tradition), Агент устанавливает традиционный способ конфигурирования данных; в этом случае значения параметров каждого интерфейса традиционной процедуры BulkCM между Менеджером и Агентом не изменяются; в противном случае, если указанный выше атрибут scenarioType имеет значение «самоконфигурирование» (self configuration), Менеджер и Агент взаимодействуют один с другим с использованием пересмотренных интерфейсов процедуры BulkCM согласно настоящему патенту.

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

Этап 401: Менеджер устанавливает в качестве способа конфигурирования данных самоконфигурирование или традиционное конфигурирование.

В частности, на этапе 401 Менеджер устанавливает атрибут scenarioType в указанном выше файле конфигурации и присваивает этому атрибуту scenarioType значение «самоконфигурирование» (способ самоконфигурирования) или «традиционный» (конфигурирование традиционным способом).

Этап 402: Менеджер обращается к интерфейсу Скачивания, чтобы передать Агенту команду скачать указанный выше файл конфигурации, содержащий данные конфигурации, из пункта, назначенного Менеджером; если атрибуту в файле конфигурации присвоено значение «самоконфигурирование», выполняется этап 403; если атрибуту в файле конфигурации присвоено значение «традиционный», проверка и активизация данных конфигурации сетевого элемента осуществляется в соответствии с традиционным способом конфигурирования.

Этап 403: Менеджер обращается к пересмотренному Контрольному интерфейсу, чтобы передать Агенту команду проверить скачанные данные конфигурации для определения их приемлемости.

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

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

В некоторых вариантах после этапа 404 может быть, в качестве опции, включен следующий этап:

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

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

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

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

Например, в Контрольный интерфейс между Агентом и Менеджером добавляют параметр scenarioType, так что этот параметр scenarioType может принимать какое-либо из следующих двух значений:

(1) «традиционный» (tradition): указывает конфигурирование данных традиционным способом;

(2) «самоконфигурирование» (self configuration): указывает самоконфигурирование данных.

После добавления указанного выше параметра scenarioType необходимо соответствующим образом настроить логические операции Контрольного интерфейса. Если параметру scenarioType присвоено значение «традиционный», Контрольный интерфейс работает в соответствии с традиционным способом конфигурирования данных, например, параметру activationMode Контрольного интерфейса присваивают значение «действительный» (valid). Если параметру scenarioType присвоено значение «самоконфигурирование», Контрольный интерфейс работает в соответствии с режимом самоконфигурирования данных (иными словами, в качестве пересмотренного интерфейса), например, параметру activationMode Контрольного интерфейса присваивают значение «недействительный» (invalid).

В дополнение к этому, в интерфейс Активизации между Агентом и Менеджером необходимо добавить еще один параметр scenarioType, так что этот параметр scenarioType может принимать какое-либо из следующих двух значений:

(1) «традиционный» (tradition): указывает конфигурирование данных традиционным способом:

(2) «самоконфигурирование» (self configuration): указывает самоконфигурирование данных.

После добавления указанного выше параметра scenarioType необходимо соответствующим образом настроить логические операции интерфейса Активизации. Если параметру scenarioType присвоено значение «традиционный», Контрольный интерфейс работает в соответствии с традиционным способом конфигурирования данных, например, исходному параметру activationMode и исходному параметру fallbacEnabled интерфейса Активизации присваивают значение «действительный» (valid). В противном случае, если параметру scenarioType присвоено значение «самоконфигурирование», Контрольный интерфейс работает в соответствии с режимом самоконфигурирования данных (иными словами, и качестве пересмотренного интерфейса), например, параметру activationMode и параметру fallbacEnabled присваивают значение «недействительный» (invalid).

После настройки указанных выше интерфейсов пятый вариант настоящего изобретения содержит в основном следующие этапы:

501: Определение способа конфигурирования данных; если сетевой элемент не имеет доступа в сеть, выполните этап 502A; если сетевой элемент получил доступ в сеть, выполните этап 502B.

502A: Менеджер обращается к указанному выше пересмотренному интерфейсу, чтобы передать Агенту команду скачать данные конфигурации для сетевого элемента от Менеджера, а также передать Агенту команду проверить данные конфигурации и сформировать фай