Плавное включение ламп накаливания

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

Технические требования, предъявляемые мной к разработке:

1 Двухполюсник
2 Мощность нагрузки от 40 до 180 Вт
3 Плавное увеличение тока в нагрузке не менее 2 секунд до максимальной мощности
4 Готовность к повторному включению не более 2 секунд

Итак, после долгого поиска и проб трех различных решений, я остановился на микросхеме 1182пм1, и на свет появилось это устройство.

Информацию о микросхеме 1182пм1 можно найти тут:
http://www.sitsemi.ru/

Все схемы, рассмотренные мной, не подходили, большинство решений страдало тем, что выход на режим для повторного включения очень долог, иногда измеряется минутами. Схемы, предлагаемые разработчиками 1182пм1, также не подходили из-за небольшой утечки тока и невозможности полного обесточивания нагрузки. Предлагаемое устройство лишено этих недостатков. Работа микросхемы представлена в описании, поэтому опишу только суть доработки. В начальный момент времени конденсатор С3 разряжен, а транзистор VT1 открыт, при подаче напряжения пиковый детектор R2VD1C4 выделяет сетевые импульсы, и транзистор VT1 начинает закрываться, конденсатор С3 заряжается, и при полном закрытии транзистора VT1 и заряде C3 симистор открывается в начале каждого полупериода сетевого напряжения и нагрузка работает на полную мощность. При отключении напряжения конденсатор C4 быстро разряжается, транзистор VT1 открывается и разряжает конденсатор C3, вся схема возвращается в исходное состояние и готова к повторному включению.

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

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

Телефонный сторож

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

Итак, было сформировано техническое задание:
1 система должна независеть от полярности в линии
2 система должна запитываться от телефонной линии
3 система не должна влиять на качество связи
4 система не должна закорачивать линию
5 система должна устанавливаться в квартире
6 система должна блокировать наборы в импульсном режиме
7 система должна блокировать наборы в тональном режиме
8 система должна выдавать индикацию об отсутствии питания на линии
9 система должна выдавать индикацию о попытке подключения


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

Разработка устройства началась с поиска решения для индикатора санкционированного занятия линии, а по простому - индикатор поднятия трубки. Индикатор должен не зависеть от полярности линии и вносить как можно меньше помех. После перебора всех известных решений была придумана простая и в тоже время эффективная схема. Индикатор построен на четырех диодах и двух оптронах. Идея заключатся в том, что при поднятии трубки через пару диодов, включенных последовательно, начинает протекать ток, и падение напряжения на них составляет примерно 1,2 вольта, чего вполне
достаточно для зажигания светодиода. Т.е. при подъеме трубки часть тока потечет через светодиод оптрона, что в свою очередь откроет транзистор.

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

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

Блоки индикации выполнены по схеме аналога однопереходного транзистора, что позволило
заряжать конденсатор малым током и при достижении порогового, зажигать светодиод.

Acme Packet - это просто. Дополнение к Части II.

При эксплуатации системы была обнаружена особенность при работе системы защиты от DDoS. Если уровень доверия выставлен в LOW, то уровень контроля может упасть до denied, при поступлении сообщений, которые отвергаются сервером или игнорируются по причине отсутствия ответа от сервера. Для изменения уровня контроля необходимо, чтобы было получено от сервера регистрации сообщение 200OK(Register), но есть особенность, при получении первого 200OK уровень изменяется на untrusted, и только при получении второго 200OK уровень изменяется на trusted. Это значит, что если произошел сбой на сервере регистраций и абонент был заблокирован, то для перехода на уровень trusted должно быть получено два сообщения 200OK. Т.к. второе сообщение генерируется по истечении таймера перерегистрации, а абонент может уже набрать номер и установить разговор после первого сообщения, то возникает ситуация, что IP адрес абонента опять превысит порог untrusted-signal-threshold и попадет в denied список. При малом пороге untrusted-signal-threshold может возникнуть ситуация, когда многопортовый шлюз не сможет перейти в trusted, т.к. для перехода в trusted два сообщения 200OK должны быть получены от одной учетной записи, а для перехода в denied достаточно любого сообщения с этого IP адреса, соответственно сообщения Register от соседних портов будут переводить весь шлюз на уровень denied. Для исключения этой ситуации изменим метод расчета untrusted-signal-threshold.

Учтем, что для успешной регистрации каждой учетной записи необходимо 2 сообщения Register, а также предусмотрим 10 сообщений для установления одного успешного разговора.

untrusted-signal-threshold = Количество портов * 2 +10

Acme Packet - это просто. Часть IV.

Upgrade

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

sftp admin@192.168.2.2
cd /code/images/
ls
nnCX_diags109.gz nnSCX620m5p4.xz nnSCX620p3.xz

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

rm nnSCX620p3.xz
put nnSCX620m6.xz

Далее изменяем bootparam

SBC-1# conf t 
SBC-1(configure)# bootparam '.' = clear field;  '-' = go to previous field;  q = quit 

file name               : /code/images/nnSCX620m5p4.xz /code/images/nnSCX620m6.xz 

Acme скажет, что система неактивна, но на это не надо обращать внимания.
Измененя в bootparam вступают в силу без записи.

Перезагружаемся.
Процесс загрузки, рекомендуется, контролировать с консоли.
Если загрузка прошла успешно, переводим сервисы на acme с новым софтом.

notify berpd force

Повторяем на второй acme.

Acme Packet - это просто. Часть III.

Защита от DOS атак - дополнение для h323.

В дополнение к первой части приводится метод расчета параметров для протокола h323.
При разработке метода использовались те же допущения, что и для SIP.

Уровень Access Control & Realm

Схема peer


Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 49600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 12480
untrusted-signal-threshold = 12480

average-rate-limit - ограничение на величину сигнального трафика, расчитывается как максимально возможная
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)

В установлении вызова участвуют следующие сообщения:

H225 CallProc - 167
H225 Progress - 226
H225 Alerting - 225
H225 Facility - 135
H225 Facility - 135
H225 Facility - 135
H225 Facility - 135
H245 TermCapSetReq - 89
H245 MSDReq - 138
H245 TermCapSetAck - 73
H245 MSDAsk - 72
H225 Connect - 248
H225 Facility - 135
H245 ReqMode - 97
H245 CloseLCAck - 74
H245 CloseLCReq - 78
H245 OpenLCAck - 93
H245 OpenLCReq - 102
H245 ReqMode - 77
H245 ReqModeAck - 74
H245 CloseLCAck - 74
H245 CloseLCReq - 78
H245 OpenLCAck - 93
H225 RLC - 117
H225 Facility - 135
H245 EndSessCmd - 72

SUM(h323 message)*30*8/30= 3077*8 = 24616 byte/sec
но такая точность нам ни к чему, несколько вольно округлим:
3100*8= 24800 byte/sec

Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 49600 byte/sec.

В результате получаем формулу расчета
average-rate-limit = 6200 * Количество портов

maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (см. выше), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*26=6240
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 12480, тем самым будут учтены возможные дополнительные сообщения.

Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 1560 * Количество портов

untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Setup, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.

Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold

Отражение VoIP

Эта колонна наилучшим образом отражает ситуацию с VoIP - также сложно создать, а то что создано - также ненадежно!

Acme Packet - это просто. Часть II.

Защита от DOS атак.

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

Итак, если вы купили пакет DDOS, то у вас появляется возможность настраивать защитные механизмы системы Acme Packet.

В системе Acme Packet можно найти следующие ограничения:
- системные ограничения - максимальное число сообщений в секунду, которое может обработать система;
- максимальная длина SIP пакета;
- максимальная длина UDP пакета;
- ограничения по IP адресам и портам;
- ограничения по протоколам;
- ограничения полезного трафика (основаны на понятиях trusted and untrusted traffic).

Мы не будем следовать этому перечислению, а пойдем по пути, который предлагает SD.

Уровень SIP Config

Ограничения на длину пакета:
sip-message-len = 2000
max-udp-length = 2000
Название параметров говорит само за себя, параметр max-udp-length изменяется в поле option.

Уровень Session Agent

Ограничение на количество сессий, налагаемое на конкретное устройство.
max-sessions = 8 - количество сессий для 8-портового шлюза, равно количеству портов на шлюзе

Для контроля за колличеством сессий нужно включить опцию:
constraints enabled


Уровень Media Manager

Если на SBC включена возможность приема ICMP пакетов, то на уровне Media Manager существует системное ограничение в 8Kbs.

max-signaling-bandwidth = 1720000 - максимальное количество сообщений, которое сможет обработать SD, значение приведено для NN3800, это значение аппаратнозависимое и отличается для других SD.

Аппаратнозависимые параметры определяющие емкость ACL.
Меняются лишь при изменении аппаратной платформы.
min-media-allocation = 2000
min-trusted-allocation = 4000
deny-allocation = 64000

arp-msg-bandwidth - полоса разрешенная для ARP запросов (по умолчанию 32000) без необходимости изменять, наверное, не надо.

flow-time-limit = 28800 - 8 часов непрерывной работы сессии (по умолчанию 24 часа)

initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-initial-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
tcp-subsq-guard-timer = 4200 - таймер срабатывает, если время между пакетами велико
Эти таймеры срабатывают при пропадании RTP потока, но также могут сработать, если передача идет лишь в одном направлении, например, при передаче факсимильного сообщения.

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

При описании модели поведения нужно описать те характеристики и ограничения, в соответствии с которыми она и будет формироваться.
- Если вызов принадлежит доверенному пользователю, этот вызов должен состояться.
- Часть злонамереннных сообщений пройдет через SD.
- Система обеспечивает обе схемы: и peer, и access.
- Схема peer запрещает любой трафик, и для разрешения требуется прописать исключение.
- Контроль за схемой access возложен на сервер регистраций.
- Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, либо при установлении соединения.
- Расчеты производим для протокола SIP.
- Для схемы peer расчет производится для входящего на шлюз вызова, а для схемы access - для исходящего, при этом учитывается максимальный сигнальный трафик.
- Каждый абонентский порт шлюза может генерировать или получать 1 вызов в секунду при максимальной нагрузке (установка сервиса автодозвон).

Весь трафик, входящий в SBC, делится на TRUSTED, UNTRUSTED и FRAGMENTED.

fragment-msg-bandwidth - полоса для фрагментированных пакетов, если fragment-msg-bandwidth = 0, то все фрагментированные пакеты идут как UNTRUSTED, и только при сборе всего пакета переходит в TRUSTED.
Предположим, что количество фрагментированных пакетов велико, для расчета предположим, что величина этого трафика может достигать половины максимально возможного, результат для NN3800: fragment-msg-bandwidth = 1720000/2 = 860000

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

max-untrusted-signaling = 6% от max-signaling-bandwidth, это максимальное значение окна в процентах от максимальной полосы, UNTRUSTED трафик не может превышать этого значения. Рекомендуемые значения для схемы peer - 1%, access - 5%, в сумме 6%.
min-untrusted-signaling = 5% от max-signaling-bandwidth, это минимальное значение окна в процентах от максимальной полосы, эта полоса всегда выделена для UNTRUSTED трафика, даже если нагрузка TRUSTED трафика приближается к 100%. Рекомендуемые значения для схемы peer - 1%, access - 4%, в сумме 5%.

Уровень Access Control & Realm

Схема peer

Пример параметров для 8-портового шлюза.
access = permit
average-rate-limit = 45600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2400
untrusted-signal-threshold = 2400

average-rate-limit - ограничение на величину сигнального трафика, расчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на шлюзе + сумма дополнительных сервисных сообщений в байтах * количество портов на шлюзе, и все это поделить на величину окна измерения (по умолчанию 30 секунд)

В установлении вызова участвуют следующие сообщения:
INVITE - 1150
PRACK - 517
ACK for Invite with Authentication - 555
BYE - 495

Сервисные сообщения:
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977

Допущение - каждый абонентский порт шлюза может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портового шлюза:
((1150+517+555+495)*30+916+790+344+977)*8/30= 22543.2 byte/sec
или
(2717*30+3027)*8/30= 22543.2 byte/sec
но такая точность нам ни к чему, несколько вольно округлим и упростим:
(2750+100)*8=2850*8= 22800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портового шлюза average-rate-limit = 45600 byte/sec.

В результате получаем формулу расчета
average-rate-limit = 5700 * Количество портов

invalid-signal-threshold - порог пакетов с ошибками, устанавливаем 0.

maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается, как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (100 Trying, 183 Session Progress, 200 OK for PRACK, 200 OK for INVITE, 200 OK for BYE), так как при входящем вызове на шлюз генерируется больше сообщений, чем при исходящем, то и рассматриваем этот вариант.
Расчет для 8-портового шлюза:
Допущение - каждый абонентский порт может получать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
8*1*30*5=1200
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2400, тем самым будут учтены возможные дополнительные сообщения.

Окончательный вариант расчета для окна 30 секунд:
maximum-signal-threshold = 300 * Количество портов

untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при ответе абонента и установлении первого разговора, то есть по Invite, приходящему на SD. Но, схема peer подразумевает, что абонент является доверенным и переход в TRUSTED не нужен, поэтому, этот параметер приравняем к maximum-signal-threshold. При этом значении не произойдет блокировки абонентского устройства при большом колличестве вызовов на занятого абонента.

Результат для схемы peer:
untrusted-signal-threshold = maximum-signal-threshold

Схема access

Пример параметров для 8-портовой PBX.
access = permit
average-rate-limit = 81600
trust-level = low
invalid-signal-threshold = 0
maximum-signal-threshold = 2880
untrusted-signal-threshold = 4

В этой схеме верны все допущения схемы peer, кроме изменения состояния; переход из UNTRUSTED в состояние TRUSTED происходит при удачной регистрации. Расчет производится для одного зарегистрированного пользователя, но так как этот пользователь может представлять из себя многопортовое устройство (например IP PBX), то и расчет производится по той же методике. Но для расчета нужно определиться с устройством, у которого будет максимальное количество портов во всей сети, скрытое за одной регистрацией, и все расчеты произвести для него.

average-rate-limit - ограничение на величину сигнального трафика, рассчитывается как
сумма сигнальных сообщений для одного вызова в байтах * количество вызовов с одного порта в течении окна измерения * количество портов на PBX + сумма дополнительных сервисных сообщений в байтах * количество портов на PBX, и все это поделить на величину окна измерения (по умолчанию 30 секунд)

В установлении вызова участвуют следующие сообщения:
INVITE - 1150
ACK - 555
INVITE with Authentication - 1400
PRACK - 517
ACK for Invite with Authentication - 815
BYE - 495

Сервисные сообщения:
REGISTER - 564
REGISTER with Authentication - 870
SUBSCRIBE - 916
NOTIFY - 790
OPTIONS - 344
REFER - 977

Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
((1150+555+1400+517+815+495)*30+564+870+916+790+344+977)*8/30= 40645.6 byte/sec
или
(4932*30+4461)*8/30= 40645.6 byte/sec
такая точность опять же ни к чему, округлим и упростим:
(4950+150)*8=5100*8= 40800 byte/sec
Учитывая, что это предельное значение, уножим на 2. Результат для 8-портовой PBX average-rate-limit = 81600 byte/sec.

Формула для расчета
average-rate-limit= 10200 * Количество портов

maximum-signal-threshold - максимально возможное количество сигнальных сообщений от пользователя в течении окна измерения (по умолчанию 30 секунд), расчитывается как максимально возвожное количество вызовов в секунду (max CPS) * окно измерения (tolerance-window) * количество сигнальных сообщений, полученых от внешнего устройства (INVITE, ACK, INVITE, PRACK, ACK, BYE).
Допущение: каждый абонентский порт PBX может генерировать 1 вызов в секунду при максимальной нагрузке (установка сервиса "Автодозвон").
Расчет для 8-портовой PBX:
8*1*30*6=1440
Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 2880, тем самым будут учтены возможные дополнительные сообщения.

Окончательный вариант расчета для окна 30 секунд -
maximum-signal-threshold = 360 * Количество портов

untrusted-signal-threshold - количество сигнальных сообщений от абонентского устройства до перевода в TRUSTED. Переход из состояния UNTRUSTED в состояние TRUSTED происходит при удачной регистрации, для удачной регистрации требуется лишь два SIP сообщения Register. Учитывая, что это предельное значение, то для устранения ложных срабатываний умножим это значение на 2, получаем 4. Но как показывает практика VoIP абонент может генерировать больше сообщений до момента удачной регистрации. Методом проб и ошибок остановились на значении 8.
Результат для схемы access:
untrusted-signal-threshold = 8