Bit error tester

Тестирование битовых ошибок (BERT)

Анализатор Greenlee DataScout 1G позволяет выполнить BERT тестирование потока E1 (2048 Кбит/с). Он предоставляет инженеру возможность вставки единичных, непрерывных, а также следующих с заданной частотой кодовых, кадровых, CRC и BPV ошибок. Это дает возможность оператору подтверждать результаты тестов и исследовать обработку ошибок тестируемой системой.

На рисунках 1 и 2 показана типовая установка для тестирования битовых ошибок в режиме шлейфа (Loopback) или в сквозном режиме «точка-точка».

После подключения кабеля Bantam или RJ-45 и настройки анализатора в меню «Настройки», нажмите кнопку «ПУСК» для начала тестирования BERT.

Тестирование битовых ошибок E1 – BERT

С использованием петли или сквозного подключения

Рисунок 1 — Тестирование BERT с закольцовыванием

Рисунок 2 — Сквозное тестирование BERT

При обнаружении ошибок значение на счетчике LOGIC (LGC) ERROR увеличивается.

Светодиодный индикатор Pattern Sync загорится зеленым цветом, если передаваемая последовательность совпадает с принимаемой.

Тестовой последовательностью BERT по умолчанию является 2-15-1. Прокручивая список влево или вправо, можно выбрать другую последовательность из списка доступных: Off (выключено), 63, 511, 2047, 2-15-1, 2-21-1, 2-23-1, QRSS, All 0 (все 0), All 1 (все 1), 1:3, 1:7, 1:15, 1:31. Для проверки правильности подключения нажмите кнопку LGC, чтобы принудительно вставить один ошибочный бит. Если счетчик ошибок LGC показывает увеличение, соединение проверено. Счетчик времени тестирования начинает отсчет после нажатия START и останавливается после STOP. После этого можно нажать на него для сброса на 0.

При необходимости можно вводить битовые ошибки с постоянным коэффициентом. Частоту битовых ошибок можно выбрать в разворачивающемся меню RATE. Чтобы начать ввод ошибок с выбранным в списке RATE коэффициентом, нажмите кнопку LGC.

Для просмотра гистограммы выбранного измерения нажмите на соответствующее поле в столбце ERROR (ошибка). Это поле изменит цвет с белого на зеленый, и ниже появится гистограмма.

Если в поле подменю для гистограмм показано ERROR INJECTION SUBMENU (подменю ввода ошибки), нажмите кнопку «Вправо» , чтобы его открыть.

Меню ALARM (тревога)

Для получения доступа к этому меню нажмите кнопку «Вправо» .

Используйте это меню для:

• Проверки того, какие сигналы тревоги вызвали включение красного светодиодного индикатора ALARM.
• Принудительного использования одного из доступных типов ошибок на передатчике E1:
  • LOS (потеря сигнала)
  • OOF (выпадение из синхронизации)
  • OOMF (выпадение из мультикадровой синхронизации)
  • AIS (индикация тревоги для всех единиц)
  • REMOTE (индикация удаленной тревоги)

Для выхода нажмите кнопку «Влево» .

Меню G.821 ERROR

Чтобы войти в это меню, нажмите в меню ALARM кнопку «Вправо» .

Источник

Bit Errror Rate Test (BERT) explained

This article will be rather short in comparison with the others in the mini-series about various Ethernet/IP testing methods but it is one that is necessary as Bit E rror Tests have a long tradition in telco environment (circuit based networks) but are still quite valid even in nowadays packet networks – at least for some specific cases. So without further delay let start with some theory behind the testing and some practical use followed by some use cases and best practices.

BERT introduction

As you can guess from the name this test is really to test physical layer traffic for any anomalies. This is a result from the test origins where T1/E1 circuits have been tested and each bit in each time-slot mattered as the providers were using those up to the limit as bandwidth was scarce. Also as most of the data being transferred were voice calls any pattern alterations had quite serious implications on the quality of service. This also led to the (in)famous reliability of five nines or the 99.999% which basically states that the link/device must be available 99.999% throughout a specified SLA period (normally a month or a year). One must remember that redundancy was rather rare so the requirements for hardware reliability was really high. But by the move away from the circuit-based TDM networks towards the packet-based IP networks the requirements changed. The bandwidth is now in abundance in most places and the wide deployment of advanced Ethernet and IP feature rich devices provides with plenty options for redundancy and QoS with packet-switched voice traffic on rise – one would think it is not really necessary to consider BERT as something one should use as test method but that would be huge mistake.

Why BERT

There are few considerations that can make BERT an interesting choice. I will list some I think are the most interesting.

• It has been designed to run for extended period of time which makes it ideal for acceptance testing which is still often required
• BERT is ideal for testing jitter as it was one of the primary design goals
• The different patters used in BERT can be used for packet optimization testing (I will discuss this later in more detail)
• Most of the BERT tests are smarter than just counting bit errors so the test can be used for other testing

BERT Physical setup and considerations

On Ethernet network you cannot run a simple L1 test unless you test just a piece of cable or potentially a hub as all other devices would require some address processing. This makes the test being different on Ethernet network from unframed E1 as unlike on E1 we need to set framing to Ethernet with the source and destination defined on the tester. Also as Ethernet must be looped on a logical level it is not possible to use simple RJ45 with pair of wires going from TX to RX as you could with E1 and either hardware or software loopback reflector is required. Most tester will actually allow you to specify even layer 3 and 4 for IP addresses and UDP ports. The reason is usually so the management traffic between tester and loopbacks can use this channel for internal communication.

Pattern selection options

As thi s test originates from the telco industry some interesting options are usually presented on the testers. The stream can generate these patterns:

• All zeros or all ones – which are specific patters originated from TDM environment
• 0101 pattern and 1010 pattern – patterns that can be easily compressed
• PRBS – Pseudo Random Bit Sequence – is an deterministic sequence that cannot be compressed/optimized the details and calculation can be found on wikipedia
• Inverted PRBS – the same as above but the calculation function is inversed to counter any “optimization” for the PRBS

The thing to remember is that PRBS will be applied to the payload of the frame/packet/datagram so it there is any sort of optimization present it will have no effect as PRBS is by design not compressible. There are various “strengths” of the pseudo-random pattern the higher the number the less repeating it will include. Normally it is possible to see two main variants: 2^15 which is 32,767 bits long and 2^23 which 8,388,607 bits long. Obviously the longer the pattern the better and more “random” behavior it emulates.

Error injecting Options

As this test originated in telco world injecting errors was a major thing but in Ethernet network it lost its importance. If you inject even a single bit error in an Ethernet frame the CRC should be incorrect and the whole frame should be dropped on first L2 equipment it will be passed through which should always result in alarm LoF(Loss of Frame)/LoP (Loss of Pattern).

Use cases, Best Practices and Conclusion

The most common use case for BERT in nowadays network would be in commissioning new links as you can run a fairly simple test for a long time that will give you a reasonable idea bout it’s quality in terms of frames drops and jitter.

The few recommendations about how to run this test would be as follows:

• Use the largest pattern you can.
• Remember that the line rate and L2 rates will be different because of the overheads.
• Remember that 99.999% of availability results in 0.8s outage in 24 hours (which can be quite a lot of frames)
• PRBS cannot be optimized

Источник

Качество сетей передачи данных. Транспорт

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

Среда передачи

Начну, пожалуй, с последнего пункта — качества среды передачи. Как уже написано выше, про нее ничего не говорилось в предыдущем повествовании, поскольку само по себе количество сред и их характеристики очень сильно различаются и зависят от просто колоссального множества факторов. Разбираться во всем этом многообразии задача соответствующих специалистов. Всем очевидно использование радио-эфира в качестве среды передачи данных. Я же помню в конце 90-х начале 00-х особой популярностью у операторов связи стали пользоваться такие экзотические способы передачи, как лазерные атмосферные передатчики. Выглядели они, в зависимости от производителя и конфигурации примерно как на картинке слева (да, почти такой себе светотелефон из радиолюбительского детства). Преимущество их было в том, что не надо было получать разрешение ГРКЧ, да и скорости, по сравнению с радиомостом были несколько больше, кроме того существовали модификации для организации каналов с временным разделением (E1 и т.п.), а подобное оборудование радио-доступа стоило непомерно дорого. Почему не оптический кабель? Потому что в те счастливые времена дикого провайдинга оптика еще была довольно дорогой, а за конвертер интерфейса или активное оборудование, способное принять оптический линк напрямую давали небольшой (а кто-то и большой) брусок золота. Были еще спутниковые каналы, но это вообще из области фантастики и позволить их себе могли разве что компании нефтяного сектора и прочего национального благосостояния. Но работа канала через спутник сводится к использованию радио-эфира, со всеми вытекающими и внесением огромной задержки.

Соответственно погружаясь в вопрос в результате будем иметь множество сред и ни одной обобщенной характеристики. Тем не менее для нас среда это всего лишь транспорт, передающий информацию из точки А в точку Б. А для транспорта (даже общественного) характеристикой отражающей его качество будет доставка всех битов (ну или пассажиров) без искажений и потерь (не хотелось бы лишиться части тела при перевозке, согласитесь). Т.е. мы приходим к такой обобщенной метрике качества транспорта как количество битовых ошибок, или BER (Bit error rate). В чисто пакетных сетях она практически не используется, поскольку ошибки передачи выявляются на уровне пакета, например подсчетом контрольных сумм: FCS (Frame check sequence) для L2 или сhecksum IP для L3. Если контрольная сумма не совпадает, то пакет целиком отбрасывается как невалидный. Если же рассмотреть гетерогенные сети, те в которых транспортом может служить непакетная сеть, а, например, один из вариантов описанных выше, либо вообще используется транзит через ATM, PDH, SDH и подобное без непосредственной (но с восстановлением) передачи пакета, то битовые ошибки транспорта могут значительно влиять, конечно в зависимости от технологии. Рассмотрим инкапсуляцию и передачу Ethernet-фрейма в HDLC. Другие технологии используют практически такую же технику.

Схема читается слева-направо (взята здесь).

1. Какой-то узел сети А отправляет пакет в сторону какого-то узла сети Б
2. Транспорт между сетями построен на сети PDH
3. Узел на границе выхода сети А вырезает из Ethernet-фрейма область полезной нагрузки (поля от DestinationAddress до FCS включительно), оборачивает в HDLC заголовки, и отправляет на граничный узел входа сети Б
4. Граничный узел входа сети Б выделяет область полезной нагрузки и восстанавливает Ethernet-фрейм
5. Фрейм с граничного узла отправляется получателю

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

Но не всегда используется надстройка инкапсуляции, либо передается вообще не полноценный фрейм, а лишь поле payload. Т.е. вырезается область, оборачивается во внутренний протокол, а на другой стороне восстанавливаются недостающие данные, включая отсутствующие заголовки L2. Соответственно пропадает и FCS — она просто рассчитывается заново. Таким образом получается, если данные были повреждены, а FCS рассчитан на основании “испорченных” данных, то получатель принимает совсем не тот пакет, который ему отправляли. Это довольно часто встречается в спутниковой связи, чтобы повысить полезную утилизацию канала, избегая передачи условно “лишней” информации. Резюмируя, получается что метрика BER может быть интересна в случаях когда:

• необходимо проверить стабильность физического канала, например для оптики это 10E-12 (упоминается в IEEE802.3)
• Ethernet-фреймы упаковывают в SDH(GFP), PDH, ATM и другие транспортные сети.
• используются технологии xHSL, PPP протоколы в которые упаковывают IP пакеты

BER тест

Метрика известна — это отношение количество битовых ошибок к общему числу переданных битов. Методика измерения для сетей TDM известна как спецификация ITU-T G.821. Классически для проверки каналов используется BERT (BER Test) первого уровня, но с учетом специфики работы протоколов инкапсуляции пакетных сетей и самого принципа работы пакетных сетей необходимо иметь возможность проводить тесты на L1-L4. Немного далее будет рассмотрено подробнее. Ну а сейчас следует определиться что проверять и как проверять. На вопрос:” Что проверять?” Отвечает ITU-T 0.150. В его пункте 5 рассмотрены типы ПСП (псевдослучайных последовательностей), из которых просто берутся данные для формирования пакета. Т.е. нужно просто взять и заполнить соответствующий уровень пакета данными выбранной ПСП. У нас в приборах используются следующие ПСП:

• ПСП 2е9 (ITU-T 0.150 пункт 5.1)
• ПСП 2е11 (ITU-T 0.150 пункт 5.2)
• ПСП 2е15 (ITU-T 0.150 пункт 5.3)
• ПСП 2е23 (ITU-T 0.150 пункт 5.6)
• ПСП 2е31 (ITU-T 0.150 пункт 5.8)
• пользовательская последовательность (32 бита)
• все нули
• все единицы
• альтернативная последовательность (01010101)

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

Вопрос как проверять пока что открыт, попробуем разобраться. Допустим мы умеем генерировать определенные пакеты. Если отправить такой пакет на другой конец транспорта, то как понять, что он не изменился (следует абстрагироваться от пакетного принципа, поскольку у нас может не быть FCS и других типов контроля, как описано ранее)? Самый простой вариант — завернуть пакет обратно (в TDM называется “сделать петлю”, в Ethernet — установить шлейф). Заворот, во многих случаях, можно сделать на выходе канала без изменения среды передачи, т.е. реально поставить петлю на выходе E1 и все будет работать. Но т.к. данные проделывают двойной путь, то вероятность возникновения ошибки также возрастает в 2 раза. Да и каналы могут быть асимметричными или однонаправленными. Соответственно идеальным было бы иметь возможность обладать информацией о корректном следовании и сравнивать приходящие пакеты с уже известной информацией. Первый, и наиболее простой вариант, применимый когда оба выхода канала располагаются рядом (например такое возможно при TDM коммутации, или тестировании оптического “кольца”) заключается в том, что один порт прибора генерирует тестовый трафик, а другой порт этого же прибора его получает и сравнивает, а т.к. сравнение происходит в том же узле, что и генерация, то проблем со сравнением данных последовательности не возникает. Второй вариант предполагает восстановление первоначальной последовательности и сравнение ее с приходящими данными. В случае с полностью случайной последовательностью реализовать такое не представляется возможным, а вот если последовательность псевдослучайная, то вполне. Какое-то время затрачивается на синхронизацию в самом начале теста, но затем сравнение не представляет сложности. Поскольку ПСП первого прибора и ПСП второго известны и одинаковы, синхронизация сводится к поиску места начала сравнения в ПСП второго прибора. Таким образом существуют следующие топологии:

1. «сам на себя» 1 — один прибор на одном порту, на другом конце транспорта стоит шлейф
2. «сам на себя» 2 — один прибор с одного порта своего порта на другой свой порт
3. с одного прибора на другой прибор, с синхронизацией

Еще раз стоит отметить, что тест BER не рекомендуется использовать на сетях лишь с пакетной коммутацией. Приведу пример. Допустим, уже идет тестовый поток и приборы синхронизированы (топология 3). В какой-то момент времени происходит следующее:

1. формируется Ethernet-фрейм, содержащий данные ПСП
2. для такого фрейма рассчитывается FCS и он укладывается в выходной буфер
3. фрейм отправляется по сети на другой прибор
4. по каким-то причинам происходит изменение всего одного бита внутри пакета
5. получатель принимает пакет
6. FCS принятого пакета не соответствует содержимому
7. пакет отбрасывается (если между отправителем и получателем есть, например, коммутатор, то “кривой” пакет вообще не дойдет до получателя, т.к. будет уничтожен до него)
8. отправитель формирует следующий пакет (все начинается с п.1)

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

А как в железе?

Как у других не знаю, но у наших приборов Беркут (ET, ETX, ETL, B100, а также модуль B5-GBE для MMT) дела обстоят следующим образом. Помня принцип о генерации и анализе трафика как можно ближе к физическому сегменту из первой статьи, все подобные задачи были возложены на FPGA. Упрощенная структурная схема выглядит так:

MAC ядро представлено двумя блоками: один на прием, другой на передачу. Это позволяет независимо принимать и отправлять пакеты, т.е. нет взаимовлияния очереди отправки на очередь приема и наоборот. Также с двух независимых блоков возможно вести общую статистику по полученному и отправленному трафику независимо от типа теста. Данные с блока передачи поступают на трансмиттер и отправляются в сеть, а входящие данные с трансивера поступают в блок приема.
Поскольку для некоторых топологий тестов необходим функционал шлейфа (loopback, петля), то он реализован отдельным блоком. Возможно установить шлейф уровня L1-L4:

• L1 — просто заворачивает трафик обратно (происходит это еще в трансивере)
• L2 — меняет DstMAC SrcMAC местами, пересчитывает FCS
• L3 — меняет DstMAC SrcMAC и DstIP SrcIP местами, пересчитывает FCS
• L4 — меняет DstMAC SrcMAC, DstIP SrcIP и DstPort SrcPort, пересчитывает FCS

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

Модуль генератора для каждого типа теста свой, для BERT он содержит генератор ПСП всех заявленных типов.
Работает это следующим образом. От генератора ПСП поступают данные на мультиплексор (проще говоря коммутатор), который, если не включен какой-то другой канал в данный момент, направляет поток в MAC tx модуль. MAC tx модуль, в соответствии с настройками теста (уровень BERT, размер пакета, данные полей) формирует из ПСП валидный Ethernet-фрейм и отправляет его в трансивер, который в свою очередь отправляет его в сеть. В зависимости от топологии теста фрейм либо заворачивается удаленной стороной, либо анализируется. В любом случае первичная обработка пакета не отличается. Фрейм попадает на MAC rx ядро, которое отправляет его на мультиплексор. Мультиплексор в зависимости от режима работы прибора направляет пакет либо в Loopback модуль, откуда после обработки он сразу же направляется в MAC tx для отправки, либо в модуль обработки и статистики теста, где, если потребуется, будет проведена попытка синхронизации ПСП и выполнено сравнение исходной последовательности с полученной. Результаты обработки отдаются в модуль вывода статистики.
Использование FPGA или ASIC позволяет все операции проводить параллельно, что не вносит какие либо задержки на обработку и исключает взаимовлияние модулей обработки.

Заключение

“И мы сделаем это. Не потому, что это легко, а потому что трудно.”

_{PS. Задавайте вопросы и предлагайте темы, в рамках нашей компетенции готовы на все 🙂}

Источник

Анализатор Greenlee DataScout 1G позволяет выполнить BERT тестирование потока E1 (2048 Кбит/с). Он предоставляет инженеру возможность вставки единичных, непрерывных, а также следующих с заданной частотой кодовых, кадровых, CRC и BPV ошибок. Это дает возможность оператору подтверждать результаты тестов и исследовать обработку ошибок тестируемой системой.

На рисунках 1 и 2 показана типовая установка для тестирования битовых ошибок в режиме шлейфа (Loopback) или в сквозном режиме «точка-точка».

После подключения кабеля Bantam или RJ-45 и настройки анализатора в меню «Настройки», нажмите кнопку «ПУСК» для начала тестирования BERT.

Тестирование битовых ошибок E1 – BERT

С использованием петли или сквозного подключения

1. Сетевой коммутатор

Рисунок 1 — Тестирование BERT с закольцовыванием

Рисунок 2 — Сквозное тестирование BERT

При обнаружении ошибок значение на счетчике LOGIC (LGC) ERROR увеличивается.

Светодиодный индикатор Pattern Sync загорится зеленым цветом, если передаваемая последовательность совпадает с принимаемой.

Тестовой последовательностью BERT по умолчанию является 2-15-1. Прокручивая список влево или вправо, можно выбрать другую последовательность из списка доступных: Off (выключено), 63, 511, 2047, 2-15-1, 2-21-1, 2-23-1, QRSS, All 0 (все 0), All 1 (все 1), 1:3, 1:7, 1:15, 1:31. Для проверки правильности подключения нажмите кнопку LGC, чтобы принудительно вставить один ошибочный бит. Если счетчик ошибок LGC показывает увеличение, соединение проверено. Счетчик времени тестирования начинает отсчет после нажатия START и останавливается после STOP. После этого можно нажать на него для сброса на 0.

При необходимости можно вводить битовые ошибки с постоянным коэффициентом. Частоту битовых ошибок можно выбрать в разворачивающемся меню RATE. Чтобы начать ввод ошибок с выбранным в списке RATE коэффициентом, нажмите кнопку LGC.

Для просмотра гистограммы выбранного измерения нажмите на соответствующее поле в столбце ERROR (ошибка). Это поле изменит цвет с белого на зеленый, и ниже появится гистограмма.

Если в поле подменю для гистограмм показано ERROR INJECTION SUBMENU (подменю ввода ошибки), нажмите кнопку «Вправо», чтобы его открыть.

Меню ALARM (тревога)

Для получения доступа к этому меню нажмите кнопку «Вправо».

Используйте это меню для:

• Проверки того, какие сигналы тревоги вызвали включение красного светодиодного индикатора ALARM.
• Принудительного использования одного из доступных типов ошибок на передатчике E1:
  • LOS (потеря сигнала)
  • OOF (выпадение из синхронизации)
  • OOMF (выпадение из мультикадровой синхронизации)
  • AIS (индикация тревоги для всех единиц)
  • REMOTE (индикация удаленной тревоги)

Для выхода нажмите кнопку «Влево».

Меню G.821 ERROR

Чтобы войти в это меню, нажмите в меню ALARM кнопку «Вправо».

Для выхода нажмите кнопку «Влево».

СОДЕРЖАНИЕ:

• Настройка анализатора Greenlee DataScout 1G

• Автоматический анализ параметров потока E1

• Мониторинг потока E1 без прекращения его работы

• Тестирование битовых ошибок (BERT)

• Измерение задержки распространения E1 (PDL)

• Анализ формы импульса E1 (Pulse Shape)