СПОСОБ И СИСТЕМА РЕАЛИЗАЦИИ СЕТЕВОГО УПРАВЛЕНИЯ НА ОСНОВЕ АРХИТЕКТУРЫ С "ТОНКИМИ" БЕСПРОВОДНЫМИ ТОЧКАМИ ДОСТУПА

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

Настоящее изобретение относится к области связи и, в частности, к способу и системе для реализации управления сетью на основе архитектуры с «тонкими» беспроводными точками доступа (АР).

Уровень техники

С тех пор как архитектура с «тонкими» АР стала новой тенденцией в индустрии беспроводных локальных сетей (WLAN) в 2002 г., сети WLAN начали управлять множеством АР через беспроводной контроллер (также называемый сетевым контроллером доступа (АС)). АС централизованно реализует обязательные стратегии и аутентификацию в системе WLAN и реализует унифицированное конфигурирование и управление для АР в системе. На Фиг.1 показана схема архитектуры управления сетью для системы с «тонкими» АР согласно соответствующим технологиям. Как показано на Фиг.1, система управления сетью в системе с «тонкими» АР состоит главным образом из платформы управления сетью, АС и АР. Платформа управления сетью главным образом реализует управление всей системой через простой протокол сетевого управления (SNMP). АС реализует конфигурирование и управление для АР главным образом на основании протокола управления и инициализации беспроводных точек доступа (CAPWAP) и протокола SNMP.

CAPWAP представляет собой основной протокол для определения взаимодействия управляющих сообщений и сообщений данных между АС и АР, и он реализует взаимодействие между АР и АС путем принятия модели «клиент/сервер» (C/S) для протокола передачи пользовательских датаграмм (UDP). Сообщение CAPWAP классифицируется как управляющее сообщение или сообщение данных. В сообщении CAPWAP главным образом используется тип сообщения для назначения функций управляющего сообщения, а элементы сообщения используются для передачи конкретных параметров.

SNMP является протоколом управления сетью, который в настоящее время наиболее широко применяется в сети, основанной на протоколе управления передачей/протоколе Интернет (TCP/IP). SNMP используется главным образом для реализации получения платформой управления сетью информации управления сетью от устройства в системе с «тонкими» АР, и устройство (что главным образом относится к АР) сообщает в систему управления сетью о проблемах и ошибках. Взаимодействие по SNMP между управлением сетью и АР необходимо направлять через АС. Протокол SNMP принимает особую форму модели C/S: модель «агент/станция управления». Управление сетью и ее обслуживание может осуществляться путем взаимодействия между управляющей рабочей станцией и агентом SNMP. Каждый подчиненный агент SNMP отвечает за ответы на различные запросы управляющей рабочей станции SNMP (главного агента) относительно информации, определяемой базой данных управления сетью (MIB). Конфигурацию и управление для АР, реализуемые платформой управления сетью, необходимо передавать через АС, и таким образом АС должен осуществлять периодический сбор данных о АР в системе посредством режима опроса. На Фиг.2 показана блок-схема сбора информации о АР платформой управления сетью в системе с «тонкими» АР согласно соответствующим технологиям. Как показано на Фиг.2, управляющая станция SNMP использует сообщение запроса Get для поиска информации от сетевого устройства, которое имеет SNMP, и агент SNMP отвечает с использованием сообщения ответа Get. Управляющая станция SNMP может осуществлять удаленное конфигурирование (включая имена устройств, свойства устройств, исключение устройств или объявление конкретного свойства устройства действительным/недействительным и тому подобное) для сетевого устройства с использованием запроса Set. Агент SNMP использует TRAP для отправки в управляющую станцию SNMP сообщения, не являющегося запросом, которое обычно используется для описания наступления определенного события.

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

Раскрытие изобретения

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

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

В случае если заданная обработка включает в себя передачу АС в АР информации конфигурации из платформы управления сетью, реализация связи между АС и АР путем использования протокола CAPWAP включает в себя этапы, на которых: АС анализирует и проверяет информацию конфигурации в формате простого протокола сетевого управления (SNMP), переданную платформой управления сетью; АС передает проанализированную и проверенную информацию конфигурации в АР по протоколу CAPWAP.

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

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

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

После того как АР сообщает о событии TRAP в АС по протоколу CAPWAP, способ дополнительно включает в себя этапы, на которых: АС реализует обработку в соответствии с событием TRAP и определяют, следует ли сообщать о событии TRAP в платформу управления сетью.

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

Между АС и АР исключена архитектура для реализации связи по SNMP.

В соответствии с другим аспектом настоящего изобретения предложена система для реализации управления сетью на основе архитектуры с «тонкими» точками доступа (АР), причем система включает в себя контроллер доступа (АС) и АР, при этом АС включает в себя: модуль связи по протоколу управления и инициализации беспроводных точек доступа (CAPWAP), выполненный с возможностью реализации связи с АР путем использования протокола CAPWAP в процессе заданной обработки; АР включает в себя: модуль связи CAPWAP, выполненный с возможностью реализации связи с АС путем использования протокола CAPWAP в процессе заданной обработки; при этом заданная обработка включает в себя по меньшей мере одно из следующего: передачи АС в АР информации конфигурации из платформы управления сетью, получения АС от АР собранной информации, которая используется для ответа на запрос сбора информации от платформы управления сетью, и сообщения АР через АС в платформу управления сетью о событии TRAP.

В случае если заданная обработка включает в себя передачу АС информации конфигурации в АР из платформы управления сетью, модуль связи CAPWAP АС выполнен с возможностью, после анализа и проверки информации конфигурации в формате простого протокола сетевого управления (SNMP), переданной платформой управления сетью, передачи проанализированной и проверенной информации конфигурации в АР по протоколу CAPWAP; в случае если заданная обработка включает в себя получение АС от АР собранной информации, которая используется для ответа на запрос сбора информации от платформы управления сетью, модуль связи CAPWAP АР выполнен с возможностью сообщения собранной информации в АС по протоколу CAPWAP; АС дополнительно включает в себя модуль хранения и модуль агента SNMP, причем модуль хранения выполнен с возможностью сохранения собранной информации, модуль агента SNMP выполнен с возможностью сообщения собранной информации, сохраненной модулем хранения, в платформу управления сетью после приема запроса сбора информации от платформы управления сетью; в случае если заданная обработка включает в себя сообщение АР в платформу управления сетью через АС о событии TRAP, модуль связи CAPWAP АР выполнен с возможностью сообщения о событии TRAP в АС по протоколу CAPWAP, когда происходит событие TRAP.

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

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

Чертежи, приведенные для более глубокого понимания настоящего изобретения и составляющие часть описания, будут использованы для пояснения настоящего изобретения вместе с вариантами выполнения настоящего изобретения, а не для ограничения настоящего изобретения, при этом:

на Фиг.1 приведена схема архитектуры управления сетью в системе с «тонкими» АР согласно соответствующим технологиям;

на Фиг.2 приведена блок-схема сбора информации для АР платформой управления сетью системы с «тонкими» АР согласно соответствующим технологиям;

на Фиг.3 приведена схема способа реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения;

на Фиг.4 приведена структурная схема системы для реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения;

на Фиг.5 приведена предпочтительная структурная схема системы для реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения;

на Фиг.6 приведена принципиальная схема оптимизированной системы управления сетью для системы с «тонкими» АР согласно варианту выполнения 1;

на Фиг.7 приведена блок-схема передачи АС по протоколу CAPWAP информации конфигурации, передаваемой платформой управления сетью, на основе структуры, показанной на Фиг.6, согласно варианту выполнения 2;

на Фиг.8 приведена блок-схема сбора оптимизированной платформой управления сетью в системе с «тонкими» АР информации о АР согласно варианту выполнения 3;

на Фиг.9 приведена блок-схема обработки АС команды GET SNMP на основе структуры, показанной на Фиг.6, согласно варианту выполнения 3.

Осуществление изобретения

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

На Фиг.3 показана схема способа реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения. Как показано на Фиг.3, в процессе заданной обработки связь между АС и АР реализована путем использования протокола CAPWAP, причем заданная обработка включает в себя по меньшей мере одно из следующего: передачи АС в АР информации конфигурации из платформы управления сетью, получения АС от АР собранной информации, которая используется для ответа на запрос сбора информации от платформы управления сетью, и сообщения АР в платформу управления сетью через АС о событии TRAP.

В соответствующих технологиях АС собирает информацию об АР путем принятия режима периодического опроса (как показано на Фиг.2); в таком случае АС должен собирать всю информацию обо всех АР, управляемых АС, в один и тот же момент, что вызывает высокую нагрузку на сеть и нагрузку обработки на АС и АР, и легко вызывает перегрузку сети, когда в системе находится множество АР, но информация пользовательских данных не может быть эффективно обработана, что сказывается на качестве сети. В способе согласно данному варианту выполнения, когда осуществляется обработка, относящаяся к управляющему взаимодействию между АС и АР, взаимодействие в отношении управляющей информации между АС и АР реализуется путем принятия протокола CAPWAP, что снижает эффективность управления сетью SNMP, снижает нагрузку на систему управления сетью и повышает качество сети.

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

В реальных применениях в отношении вышеуказанной заданной обработки процедура реализации связи между АС и АР путем использования протокола CAPWAP может быть реализована, обращаясь к процессам, описанным ниже.

(1) В случае если заданная обработка включает в себя передачу АС в АР информации конфигурации из платформы управления сетью:

АС может анализировать и проверять информацию конфигурации формата SNMP, передаваемую платформой управления сетью, и затем передавать проанализированную и проверенную информацию в АР по протоколу CAPWAP.

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

(2) В случае если заданная обработка включает в себя получение АС от АР собранной информации, которая используется для ответа на запрос сбора информации от платформы управления сетью:

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

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

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

(3) В случае если заданная обработка включает в себя сообщение АР через АС в платформу управления сетью о событии TRAP:

АР сообщает о событии TRAP в АС по протоколу CAPWAP в случае, если происходит событие TRAP; АС осуществляет обработку в соответствии с событием TRAP и определяет, следует ли сообщить о событии TRAP в платформу управления сетью.

Благодаря вышеописанному способу реализуется связь между АС и АР по протоколу CAPWAP в случае, если АР сообщает через АС в платформу управления сетью о событии TRAP.

Учитывая, что конфликт между двумя видами конфигурации с легкостью возникает, когда АС передает информацию о конфигурации по двум видам каналов, т.е. по каналу SNMP и по каналу CAPWAP, в качестве предпочтительного решения может быть исключена архитектура реализации связи по протоколу SNMP между АС и АР, чтобы снизить сложность АС и АР и повысить производительность обработки АС и АР. Кроме того, если впоследствии необходимо добавить другие узлы управления сетью (такие, как TR069), требуется лишь выполнить соответствующую адаптивную обработку в АС в отношении запроса конфигурации вновь добавляемых узлов управления сетью и нет необходимости изменять АР, что значительно увеличивает способность к расширению системы управления сетью.

На Фиг.4 показана структурная схема системы для реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения. Система включает в себя АС 42 и АР 44, причем АС 42 включает в себя: модуль 422 связи CAPWAP, выполненный с возможностью реализации связи с АР 44 путем использования протокола CAPWAP в процессе заданной обработки; АР 44 включает в себя: модуль 442 связи CAPWAP, выполненный с возможностью реализации связи с АС 42 путем использования протокола CAPWAP в процессе заданной обработки. Заданная обработка включает в себя по меньшей мере одно из следующего: передачу АС 42 в АР 44 информации конфигурации из платформы управления сетью, получение АС 42 от АР 44 собранной информации, которая используется для ответа на запрос сбора информации от платформы управления сетью, и сообщение АР 44 через AC 42 в платформу управления сетью о событии TRAP.

Предпочтительно в случае, если заданная обработка включает в себя передачу АС 42 в АР 44 информации конфигурации от платформы управления сетью, модуль 422 связи CAPWAP АС 42 выполнен с возможностью, после анализа и проверки информации конфигурации в формате SNMP, передаваемой платформой управления сетью, передачи проанализированной и проверенной информации конфигурации в АР 44 по протоколу CAPWAP.

На Фиг.5 показана предпочтительная структурная схема системы для реализации управления сетью на основе архитектуры с «тонкими» АР согласно варианту выполнения настоящего изобретения. Как показано на Фиг.5, в случае если заданная обработка включает в себя получение АС 42 от АР 44 собранной информации, используемой для ответа на запрос сбора информации от платформы управления сетью, модуль 442 связи CAPWAP АР 44 выполнен с возможностью сообщения собранной информации в АС 42 по протоколу CAPWAP; АС 42 дополнительно включает в себя модуль 424 хранения и модуль 426 агента SNMP, причем модуль 424 хранения выполнен с возможностью сохранения собранной информации, модуль 426 агента SNMP выполнен с возможностью сообщения собранной информации, сохраненной модулем хранения, в платформу управления сетью после приема запроса сбора информации от платформы управления сетью.

Предпочтительно в случае, если заданная обработка включает в себя сообщение АР 44 через АС 42 в платформу управления сетью о событии TRAP, модуль 442 связи CAPWAP АР 44 выполнен с возможностью сообщения о событии TRAP в АС 42 по протоколу CAPWAP, когда происходит событие TRAP.

Технические решения множества предпочтительных вариантов выполнения объединены в описанных ниже вариантах выполнения 1-3.

Вариант выполнения 1

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

(1) Информацию конфигурации, передаваемую платформой управления сетью, АС передает по протоколу CAPWAP вместо SNMP.

После анализа и проверки информации конфигурации SNMP, передаваемой платформой управления сетью SNMP, АС передает проанализированную и проверенную информацию в АР по протоколу CAPWAP и сохраняет проанализированную и проверенную информацию в базе данных (DB). Таким образом АС передает информацию конфигурации в АР только по каналу CAPWAP.

(2) Режим сбора информации изменяется на режим, в котором АР активно сообщает информацию по протоколу CAPWAP из режима, в котором АС осуществляет сбор посредством опроса по SNMP. АР активно сообщает собранную информацию после о рабочих характеристиках по протоколу CAPWAP. Когда платформа управления сетью собирает информацию, АС непосредственно считывает соответствующую информацию конфигурации или информацию статистики по рабочим характеристикам из DB.

Поскольку АР в архитектуре с «тонкими» АР является элементом без конфигурации, АС не требуется получать информацию конфигурации АР от АР, но требуется получать от АР информацию статистики по рабочим характеристикам АР. В соответствии с фактическими условиями АР может сообщать информацию статистики по рабочим характеристикам в АС по протоколу CAPWAP, и АС сохраняет информацию статистики по рабочим характеристикам в DB; АС считывает информацию статистики по рабочим характеристикам непосредственно или информацию статистики по рабочим характеристикам из DB, когда платформа управления сетью SNMP собирает упомянутую информацию.

(3) АР сообщает о событии TRAP по протоколу CAPWAP вместо SNMP.

После того как происходит конкретное событие (событие TRAP), АР сообщает об упомянутом конкретном событии в АС по протоколу CAPWAP. АС реализует относительную обработку в соответствии с конкретной информацией о событии и определяет, следует ли сообщать в платформу управления сетью SNMP. Таким образом, АР сообщает о конкретном событии в АС только по каналу CAPWAP.

На Фиг.6 показана принципиальная схема оптимизированной системы управления сетью для системы с «тонкими» АР согласно варианту выполнения 1. Как показано на Фиг.6, после того как взаимодействие между АС и АР унифицировано в виде режима CAPWAP, соответствующая реализация взаимодействия по SNMP между АС и АР может быть исключена, что снижает сложность АС и АР и повышает производительность обработки АС и АР. Кроме того, если впоследствии потребуется добавить другие узлы управления сетью (такие, как TR069), необходимо выполнить лишь соответствующую адаптивную обработку для АС в отношении запроса конфигурации вновь добавляемых узлов управления сетью, а в АР не нужно вносить никаких изменений, что значительно увеличивает способность к расширению системы управления сетью.

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

Вариант выполнения 2

На Фиг.7 показана блок-схема передачи АС по протоколу CAPWAP информации конфигурации, передаваемой платформой управления сетью на основании структуры, показанной на Фиг.6, согласно варианту выполнения 2. Как показано на Фиг.7, процесс включает в себя следующие этапы:

этап 1 - платформа управления сетью передает запрос Set SNMP в агент SNMP в АС, причем запрос Set SNMP включает в себя информацию конфигурации для АР, обеспеченную платформой управления сетью;

этап 2 - агент SNMP проверяет информацию конфигурации и затем сохраняет информацию конфигурации в DB, устанавливает действительность проанализированной и проверенной информации конфигурации и конфигурирует информацию в модуль CAPWAP;

этап 3 - модуль CAPWAP передает информацию конфигурации в АР в запросе CAPWAP по протоколу CAPWAP;

этап 4 - АР возвращает ответ CAPWAP в модуль CAPWAP, и конфигурирование осуществляется успешно.

Вариант выполнения 3

На Фиг.8 показана блок-схема сбора оптимизированной платформой управления сетью системы с «тонкими» АР информации о АР согласно варианту выполнения 3. Процесс включает в себя следующие этапы:

этап 1 - АР сообщает информацию конфигурации или информацию статистики по рабочим характеристикам АР в АС посредством запроса CAPWAP;

этап 2 - АС возвращает ответ CAPWAP;

этап 3 - платформа управления сетью отправляет информацию запроса Get SNMP в АС для запроса сбора информации о АР;

этап 4 - АС возвращает информацию ответа Get SNMP в платформу управления сетью, причем информация ответа Get SNMP содержит информацию конфигурации или информацию статистики по рабочим характеристикам о АР.

На Фиг.9 показана блок-схема обработки АС команды GET SNMP на основании структуры, показанной на Фиг.6, согласно варианту выполнения 3. Процесс включает в себя следующие этапы:

этап 1 - АР сообщает информацию конфигурации или информацию статистики по рабочим характеристикам АР в модуль CAPWAP АС посредством запроса CAPWAP;

этап 2 - модуль CAPWAP АС возвращает ответ CAPWAP и сохраняет принятую информацию конфигурации или информацию статистики по рабочим характеристикам в DB АС;

этап 3 - агент SNMP АС принимает информацию запроса Get SNMP от платформы управления сетью, причем информация запроса Get SNMP запрашивает сбор информации о АР;

этап 4 - агент SNMP АС возвращает информацию ответа Get SNMP в платформу управления сетью после считывания данных из DB, причем информация ответа Get SNMP содержит информацию конфигурации или информацию статистики по рабочим характеристикам АР.

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

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

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