Анализ качества работы подсистемы SSS на основе KPI Анализ емкости подсистемы SSS
Поддержка 1-го уровня с выездом на сайты
Разработка значений логических параметров для эффективной работы опций
Предложения по внедрению новых опций
Анализ параметров базы данных контроллеров и их корректировка Проверка измененных параметров баз данных контроллеров и их уточнение
· Разработка значений логических параметров БС и их последующая настройка
· Анализ взаимосвязанных логических параметров (особенно соотношения таймеров)
· Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.
· Предложения по установке логических параметров в случае активации новых опций
· Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.
· Поддержка с выездом на сайт при проведении инспекции установленного оборудования, согласно техническим предписаниям и нормам по монтажу и эксплуатации оборудования.
При оптимизации подсистемы коммутации решаются следующие задачи:
Определение основных показателей качества (KPI)
· Проводится согласование списка показателей качества, по которым проводится оценка сети, а также формул для вычисления KPI.
· Оговариваются значения, которые предполагается достичь в результате оптимизации.
Транкгруппы. Анализ позволяет получить представление о:
· состоянии
· количестве
· степени загруженности (utilisation rate, mErl)
· ошибках
для каждой из транкгрупп в ЧНН.
Нагрузка на LTG. Анализ позволяет получить представление о
· статической нагрузке (мЕрл)
· динамической нагрузке (попытки вызовов)
для каждой из LTG
Сигнальная сеть SSNC. Анализ MP и C7 линков позволяет получить представление о
· нагрузке на линксет и каждый линк в частности (мЕрл)
· рапределении нагрузки в пределах линксета
· наличии ретранслированных октетов
· динамической нагрузке МР
· Соединения, маршрутизация и SDDPFC
· Нумерация
· Обработка глобальных заголовков (GTT)
· Зависимые друг от друга команды
· ODAGEN
· Сравнение частей баз данных на разных сетевых элементах
· Создание корректирующих баз данных
· Установка корректирующих баз данных
31 краткое описание команд распространенных протоколов
Соединиться по какому-либо протоколу" - слышали такие слова? Кто они, вообще, эти протоколы передачи данных? Этой теме и посвящена данная статья (эта статья несколько сложней для восприятия, чем большинство статей на этом сайте).
Начнем с того, что протокол - это просто установленный "язык" общения программ. Вообще, что такое пересылка данных? По кабелю отправляется последовательность "битов" - нулей или единиц. Но почему этот поток доходит до целевого компьютера и что тот собирается с этим потоком делать? Естественно, должны существовать некоторые правила формирования данных, и эти правила описываются стандартными протоколами.
Про протоколы также обычно говорят, что имеются уровни вложенности сетевых протоколов. Что это означает? Во-первых, есть так называемый физический уровень. Это - просто список определений, каким должен быть сетевой кабель, толщину жил и так далее. Допустим, теперь, кабель исправен. Тогда по нему могут отправляться пакеты с данными. Но какой компьютер примет пакет? Здесь задействуется так называемый канальный уровень - в заголовке пакета указывается физический адрес компьютера - некоторое число, зашитое в сетевой карте (не IP-адрес, а MAC-адрес).
Канальный уровень = уровень Ethernet. Как вы видите (картинку я взял с википедии), пакет содержит некоторый параметр Ethertype, задающий тип пакета. Сами данные зависят от этого типа, и их содержание уже находится на сетевом уровне. Наиболее распространены два протокола: ARP, отвечающий за преобразование IP-адресов в MAC-адреса; и самый существенный протокол - IP. Приведем структуру пакета IP (детализация поля "Data" предудущего рисунка)
Все данные, переносимые по IP уже пересылаются на конкретный IP-адрес (это не мешает посылать широковещательных запросы всем компьютерам локальной сети - просто указывается специальный IP-адрес, например, 192.168.255.255). У протокола IP тоже есть разновидности - в пакете в установленном формате передается число, обозначающее тип протокола. Например, одним из типов протоколов, подчиненных IP, является ICMP, используемый командой ping для проверки, откликается ли компьютер.
Но наиболее распространены два следующих типа: TCP - Transmission Control Protocol и UDP - universal datagram protocol (кстати, мы уже поднялись на транспортный уровень). Отличие же между этими протоколами таково: про протокол TCP говорят, что он "надежный", то есть в процессе обмена данными производится постоянная проверка: а дошел ли пакет до цели? А протокол UDP не предусматривает никакого контроля - отправили дейтаграмму и забыли. Когда такое нужно? Очень просто, например, при прослушивании интернет-радио. Если был сбой и пакет до вас вовремя не дошел, он уже не нужен - просто проскользнули помехи - и вы слушаете дальше. Приведем структуру TCP-пакета (детализация поля "данные" с предудущего рисунка).
Как мы видим, в пакете указывается номер порта, на который отправлен пакет. Обычно номер порта определяет тип протокола на прикладном уровене - какому именно приложению отправлены эти данные. Однако ничего не запрещает использовать нестандартные порты для своих сервисов - просто менее удобно будет пользователям. Наиболее известные протоколы - http (просмотр страниц в интернете), pop3 (получение почты). Чтобы не повторяться, отошлю к списку стандартных портов. Сами данные, получаемые приложением вкладываются в TCP-пакет (поле "данные").
Таким образом, мы получили своеобразную иерархию вложенности пакетов. В Ethernet-пакет вложен IP-пакет, в него TPC или UDP-пакет, а в него - данные, предназначенные конкретному приложению. Просто смерть кащея какая-то.
Что еще интересно, протокол DHCP, отвечающий за получение IP-адреса по MAC-адресу, также находится на прикладном уровне (по умолчанию использует UDP порты 67 и 68) - хоть у компьютера еще нет IP-адреса, он может отсылать широковещательные запросы согласно сетевым настройкам. То же самое можно сказать про протокол DNS, выясняющий IP-адрес по доменному имени.
32 формальные методы описание протоколов
Число эксплуатируемых в настоящее время протоколов обмена данными велико; при этом разрабатываются все новые протоколы, обеспечивающие лавинное развитие сетевых технологий (появилась новая область вычислительной техники, называемая ‘протокольной технологией’).
Классическое (неформально-словесное, например, ранее упомянутые
RFC-документы) описание протокольных соглашений имеет ряд недостатков; важнейшие из них - не позволяющая однозначно согласовывать разрабатываемые стандарты субъективная природа восприятия словесных описаний (следствие - описания не имеют полноты и основы для анализа), возникают трудности и труднолокализируемые ошибки при создании реализующих эти протоколы программных и аппаратных средств.
По сравнению со словесными формальные описания обладают существенными преимуществами - они строги и однозначны, лежащие в основе конкретного метода формального описания модели позволяют выполнить анализ (верификацию) описаний, а также автоматизировать процесс трансляции этих описаний непосредственно в машинную реализацию.
Формальные методы описания протоколов могут быть разбиты на две группы - методы первой группы рассматривают объект как автомат (т.н. ‘автоматные методы’), методы второй группы - как ‘черный ящик’, характеризующийся только внешним поведением (т.н. ‘методы последовательностей’).
В качестве представителя первой группы может быть приведен язык ESTELLE (Extended State Transition Language), второй - язык LOTOS
(Language of Temporal Ordering Specification); оба языка разработаны Международной организацией стандартов (ISO) и служат базовыми средствами для описания разрабатывающих международных стандартов [8].
Язык ESTELLE (1983 г.) основан на объединении логики конечного ав-
томата (при добавлении элементов описания архитектурных особенностей
протокольных систем) и языка программирования Pascal; применяемые в
языке LOTOS (1984 г.) методы основаны на концепции временного упорядо-
чения примитивов взаимодействия.
В СССР для конкретного программно-аппаратного окружения был раз-
работан (в рамках инструментального комплекса ‘Архитектор’) реализую-
щий ‘автоматный метод’ язык ОСА (Описание Сетевых Архитектур, основы
и принципы языка впервые опубликованы в 1983 г.), предназначенный для реализации протокольных архитектур на вычислительных комплексах ‘Эльбрус’. В комплект системы входят развитые средства анализа описаний на языке ОСА и средства тестирования и отладки (под конкретную аппаратную часть). С помощью языка OCA были разработаны специализированные протоколы канального и сетевого уровней, транспортный и сеансовый протокол, протоколы для передачи информации и файлов, удаленного диалога и протокол удаленного запуска заданий (некоторый функциональный аналог RPC в Windows’NT).
Кроме вышеприведенных, известны системы проектирования и описания протоколов FAPL (Format and Access Protocol Language, 1978), PANDORA (Protocol Analysis, Design and OpeRation Assesment, 1982), PDIL (Protocol Description and Implementation Language, 1982), ПРАНАС (Каунас-
ский политехнический институт, 1985) и др.
Как и в случае традиционных языков программирования, исходный
текст на языке формального описания протоколов транслируется (после этапа отладки) в машинный код, исполняемый часто (специализированными) процессорами передачи сообщений (IMP - Interface Message Processor).
