Широкополосные кабельные сети : RF HRC

FEC-ошибки входящего и исходящего потоков данных и отношение сигнал-помехи (SNR) как способы контроля качества данных и пропускной способности

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (11 сентября 2015) | Отзыв


Содержание


Введение

Для работы высокоскоростной сети передачи данных (HSD) по гибридному оптоволоконному / коаксиальному кабелю (HFC) необходим тщательный контроль качества на заводе по производству кабеля. Только в этом случае возможно гарантировать целостность данных и максимальную пропускную способность канала передачи данных. Существуют два общепринятых метода измерения операторами кабельных сетей качества передачи данных: измерение уровня ошибок в канале связи (BER) и изменение уровня ошибок в пакетах (PER).

Data Over Cable Service Interface Specification (DOCSIS) выделяет требования, чтобы каждый оператор кабельной связи поддержал для надежной транспортировки трафика данных IP. Важная функция DOCSIS обращается к потребности защитить данные IP против ухудшений шума радиочастот (RF). Особенностью использования функции DOCSIS для поддержки целостности данных IP на участках кабеля HFC является кодирование FEC Рида-Соломона.

По существу кодирование FEC защищает данные IP и Сообщения управления DOCSIS против ошибок символа, вызванных шумом и другими ухудшениями. Уникальной возможностью FEC является обнаружение ошибок символов и их исправление. Таким образом DOCSIS указывает, что все данные IP, которые переданы по Участку HFC, должны пройти через Кодировщика Рида-Соломона, где байты дополнительной четности добавлены к фреймам данных, чтобы гарантировать, что они “защищены от ошибки” и менее подвержены ухудшениям.

Примечание: FEC не работает очень хорошо, если ошибки созданы импульсным шумом, который создает много ошибок по очереди. Вызванные импульсным шумом ошибки устранены на нисходящем с использованием чередования, чтобы заставить ошибки казаться распространенными, какой FEC является эффективным при решении проблемы. DOCSIS 2.0 добавил интервалы в восходящем направлении — который помогает с этим типом восходящих (US) ухудшению — но это не доступно на 1.x кабельные модемы (CM).

Несомненно адрес возврата кабельной сети или в восходящем направлении особенно уязвим для шума и отнесенных ухудшений. Такие помехи могут быть импульсными, входными, тепловыми помехами, лазерным отсечением и т.д. При использовании кодирования FEC вероятность того, что пакет будет отброшен из-за битовых ошибок, значительно возростает. Ошибки FEC на кабельном участке не являются единственной качественной мерой. Необходимо учитывать и другие переменные, например отношение "сигнал/шум" для несущей частоты (CNR).

Стандарт DOCSIS содержит рекомендованные параметры производительности как для нисходящего, так и для восходящего кабеля TV RF. В частности, Раздел 2.3.2 из спецификации интерференции радиочастоты (RFI), “Принятые восходящие Характеристики передачи Канала ВЧ”, сообщает это:

Отношение сигнал-помеха дополнительный вход (сумма шума, искажения, искажения общего пути и перекрестной модуляции и суммы дискретных и широкополосных входных сигналов, исключенный импульсный шум) соотношение [не будет] меньше чем 25 дБ.

Другими словами, минимальный DOCSIS рекомендовал, чтобы CNR US составил 25 дБ. В целях этого документа CNR определен как отношение уровней несущей и сигнала шума, прежде чем это достигнет микросхемы демодулятора (домен RF), как измерено анализатором спектра. С другой стороны SNR определен как отношение сигнала к шуму от микросхемы US - получателя (CMTS) системы терминирования кабельных модемов после того, как носитель демодулировался для предоставления чистой узкополосной передачи, отношения сигнала к шуму.

Таким образом, при просмотре считывания SNR в Cisco uBR7246 и появления такого числа как 30 дБ легко предположить, что восходящий поток появляется для соответствия или даже превышения DOCSIS, а в RF все нормально. Однако это не всегда так. DOCSIS не задает SNR, и оценка SNR CMTS не является той же вещью как CNR, который каждый измеряет с анализатором спектра.

Этот документ обсуждает предполагаемый расчет для восходящего потока SNR uBR, и также FEC uBR противостоит и показывает, почему эти две переменные должны постоянно оцениваться для обеспечения качества HSD в средах HFC.

Отношение сигнала к шуму

Оценка SNR uBR может иногда вводить в заблуждение и должна быть рассмотрена только отправная точка когда дело доходит до проверки целостности восходящего диапазона радиочастот. Чтение SNR на линейной плате MC16C uBR предоставлено микросхемой US, но чтение является не обязательно надежным показателем “реальных” ухудшений RF, таких как импульсивный шум типа, отдельный вход, и т.д. Кроме того, считывание US SNR неточно. Когда CNR находится в диапазоне на 15 - 25 дБ, в средах с немногими ухудшениями на восходящем (например, импульсный шум, вход, искажение общего пути, и т.д), оценка SNR US численно отслеживает CNR меньше чем в нескольких децибелах. Это точно с аддитивным белым нормально распределенным шумом (AWGN) как единственное ухудшение; в реальных условиях, однако, может варьироваться точность этого количества. Это зависит от природы ухудшений и лучше отражает коэффициент ошибок модуляции (MER), а не CNR.

Как получить чтения CNR и SNR

Этот раздел показывает несколько примеров того, как получить восходящую оценку SNR из Cisco uBR7200, и uBR10K (также см. Приложение). Все выходные данные команды и command интерфейса командной строки (CLI) взяты от Cisco Выпуск ПО IOS� 12.2 (15) BC2a, пока в противном случае не задано.

Обратите внимание на то, что “S карта” обращается к кабельной линейной карте со встроенными аппаратными возможностями спектрального анализа, тогда как “карта C” обращается к кабельной линейной карте без этой возможности. При определенной настройке параметров S-карта сообщает показатели CNR, а не SNR, поскольку на ней имеются встроенные аппаратные средства анализа спектра.

Совет: При сборе выходных данных команд CLI программного обеспечения Cisco IOS в целях устранения проблем или для передачи технической поддержке Cisco, не забудьте включать метку времени приглашения terminal exec, так, чтобы каждая линия выходных данных команды CLI сопровождалась меткой времени и текущей Загрузкой ЦПУ на CMTS.

Для карт S:

ubr7246# show controller cable6/0 upstream 0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable6/0 Upstream 0 is up
  Frequency 21.810 MHz, Channel Width 3.2 MHz, 16-QAM Symbol Rate 2.560 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement - 38 dB

Для карт C или карт S без назначенных групп спектра:

ubr7246vxr# show controller cable3/0 upstream 0

Load for five secs: 10%/1%; one minute: 7%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035

Рекомендуется, чтобы вы поддержали набор уровня US в по умолчанию 0 дБмВ и использовали внешние аттенюаторы, чтобы вынудить модемы передать в более высоких уровнях, при необходимости.

ubr7246# show cable modem phy

MAC Address    I/F     Sid USPwr  USSNR  Timing MicrReflec DSPwr DSSNR Mode
                          (dBmV)  (dB)   Offset (dBc)     (dBmV) (dB)
0002.8a8c.6462 C6/0/U0  9  46.07  35.42  2063   31        -1.05  39.05  tdma
000b.06a0.7116 C6/0/U0  10 48.07  36.12  2037   46         0.05  41.00  atdma

Совет: Даже если о CNR сообщают в команде show controllers, команда phy может использоваться для создания отчетов о SNR. Это особенно полезно, потому что о SNR сообщают после того, как отмена внешнего доступа выполнена, и о CNR сообщают перед отменой внешнего доступа.

Примечание: SNR указывается для каждого модема в коде EC с результатами команды show cable modem detail.

Если remote-query настроен, команда phy также перечисляет другие атрибуты физического уровня. Эти три строки кода можно ввести для активации удаленного запроса:

snmp-server manager
snmp-server community public ro
cable modem remote-query 3 public

Для быстрого отзыва использовалось значение 3 сек. Не рекомендуется применять его в CMTS со значительной нагрузкой. Строка по умолчанию строки имени и пароля только для чтения в большинстве модемов является общедоступной.

Примечание: Игнорируйте запись микроотражений, потому что это для ДВУХСТОРОННЕЙ ДИСКЕТЫ и ограничено точностью реализации Поставщика CM.

ubr7246# show cable modem 000b.06a0.7116 cnr

MAC Address    IP Address      I/F      MAC     Prim  snr/cnr
                                        State   Sid   (dB)
000b.06a0.7116 10.200.100.158  C6/0/U0  online  10     38

Эта команда перечисляет SNR при использовании С платы. Если используется S-карта и назначены группы спектра, выдается CNR. Команда show cable modem mac-address verbose также работает.

Как просмотреть минимальный уровень шума

S-платы позволяют также просматривать минимальный уровень шума с помощью следующей команды:

ubr7246-2# show controller cable6/0 upstream 0 spectrum ?

  <5-55>              start frequency in MHz
  <5000-55000>        start frequency in KHz
  <5000000-55000000>  start frequency in Hz
  A.B.C.D             IP address of the modem
  H.H.H               MAC address of the modem

Добавление IP модема или MAC-адреса к команде показывает пакетное питание модема и ширину канала.

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 ?

  <1-50>  resolution frequency in MHz

ubr7246-2# show controller cable6/0 upstream 0 spectrum 5 55 3

Spect DATA(@0x61359914) for u0: 5000-55000KHz(resolution 3000KHz, sid 0:
Freq(KHz) dBmV Chart
5000 :    -60
8000 :    -23  ****************
11000:    -45  *****
14000:    -46  *****
17000:    -55
20000:    -60
23000:    -60
26000:    -55
29000:    -18  *******************
32000:    -60
35000:    -60
38000:    -60
41000:    -55
44000:    -45  *****
47000:    -60
50000:    -60
53000:    -41  *******

Те выходные данные показывают шум под носителем и в других частотах.

В дополнение к CLI на основе SNMP Средства управления сетью, такие как Cisco Broadband Troubleshooter (CBT) могут использоваться для показа спектра восходящего канала и других атрибутов. Кроме того, CiscoWorks может использоваться для мониторинга SNR, как сообщается кабельными линейными картами с помощью объекта docsiIfSigQSignalNoise:

DOCS-IF-MIB
docsIfSigQSignalNoise	.1.3.6.1.2.1.10.127.1.1.4.1.5
	Signal/Noise ratio as perceived for this channel.
 	At the CM, describes the Signal/Noise of the downstream
 	channel.  At the CMTS, describes the average Signal/Noise
 	of the upstream channel.

Примечание: Отдельные Чтения SNR CM только доступны на линейных платах MC28U и MC5x20S. Эти новые линейные карты включают отмену внешнего доступа, которая может улучшить производительность, но может дать вводящие в заблуждение Чтения SNR. Чтения SNR после отмены внешнего доступа; таким образом, если отмена внешнего доступа математически удаляет вход, то SNR мог сообщить намного лучше, чем фактическое отношение несущая/помеха.

Примечание: При использовании групп спектра на карте S команда show controllers случайным образом выбирает чтения CNR от всех CM на том US, который мог немного отличаться, давая появление нестабильного порта US или CNR.

Восходящие несущие в нулевом диапазоне

Использование значимости режима в анализаторе спектра является режимом нулевого диапазона. Это режим изменения во времени, в котором отображается не зависимость амплитуды от частоты, а зависимость амплитуды от времени. Этот режим очень удобен для просмотра трафика данных, пакетного по своей природе. Рисунок 1 показывает анализатор спектра в нулевом диапазоне (промежуток времени) при рассмотрении трафика восходящего направления от CM.

Рисунок 1 – показ нулевого диапазона на анализаторе спектра

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-1.jpg

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

Рисунок 2 – измерение нулевого диапазона восходящего потока в цифровой форме амплитуда модулированной несущей

return_path_monitor_2.gif

Нулевой диапазон может также использоваться, чтобы видеть, сталкиваются ли пакеты друг с другом от плохой синхронизации или плохой изоляции разделителя головных узлов или изоляции сумматора. Пакет, предназначенный для одного входного порта CMTS, “протекает” на другой восходящий. Сошлитесь на Описания технологических решений и документы, перечисленные в разделе "Дополнительных сведений" этого документа. Для получения описания процедуры измерения нулевого диапазона см. "Подключение маршрутизатора Cisco серии uBR7200 к головной станции кабельной сети".

Фактически все повреждения RF, упомянутые до сих пор в этом документе, могут ухудшать эффективность восходящего канала и проявляться в низкой пропускной способности передачи данных, что не обязательно отражается низким SNR. Наблюдение неустранимых ошибок FEC (аналогичный плохому BER и PER) — даже при том, что SNR, кажется, выше минимального стандарта DOCSIS — могло указать к другим переходным проблемам, которые должны быть решены. Возможно, посторонний CM вызывает ошибку и низкий уровень чтения SNR для всех других CM на одном и том же US. В этом случае CNR, как измерено на анализаторе спектра выглядел бы хорошо, но CMTS сообщит в противном случае.

Прямое исправление ошибок

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

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

  • помехи наружного передатчика

  • перегрузка усилителя (сжатие, которое является формой отсечения),

  • лазерное отсечение

  • импульсный шум или входные помехи

  • свободный или нестационарные соединения

  • плохая изоляция сумматора или разделителя восходящего канала

  • неисправные модемы

Существует два метода, с которыми может собрать информацию FEC:

  • CLI

  • Опрос с использованием идентификаторов объектов SNMP (OID)

Пример сбора данных FEC с помощью CLI (также см. Приложение):

ubr7246vxr# show controller cable3/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Interface Cable3/0
Hardware is MC16C

!--- Output suppressed.

 Slots 937882 NoUWCollNoEngy 82 FECorHCS 4 HCS 4
 Req 1160824263 ReqColl 350 ReqNoise 96 ReqNoEnergy 1160264889
 ReqData 0 ReqDataColl 0 ReqDataNoise 0 ReqDataNoEnergy 0
 Rng 609652 RngColl 0 RngNoise 76
 FECBlks 1638751 UnCorFECBlks 7 CorFECBlks 4
  • FECBlks — Общее число блоков FEC (и хороший и плохой) полученный всеми входными портами связалось с данным нисходящий.

  • UnCorFECBlks — Общее число блоков FEC, полученных всеми входными портами, связалось с данным нисходящий, которые были так повреждены шумом или входом, что они не могли быть исправлены или восстановлены алгоритмом FEC.

  • CorFECBlks — Общее число блоков FEC, полученных всеми входными портами, связалось с данным нисходящий, которые были немного повреждены шумом или входом, и это могло быть исправлено и восстановлено алгоритмом FEC.

Пакеты обслуживания станции инкрементно увеличивают счетчик FECBlks приблизительно 2 в x секунды, где x является минимальным интервалом опроса (как отображено в команде show cable hop) разделенный на 1000. Удаленный запрос также инкрементно увеличивает этот счетчик, как делает начальное обслуживание, когда модемы прибывают онлайн. Поскольку начальное обслуживание происходит в течение состязательного времени, могли быть коллизии и последующие неустранимые ошибки FEC.

Совет: Убедитесь, что модемы не располагаются или прибывают онлайн прежде, чем предположить, что US нестабилен просто, потому что инкрементно увеличиваются неисправимые счетчики FEC. Кроме того, значение NoUwCollNoEngy могло бы увеличиться, если существуют модемы с проблемами синхронизации. Уникальное слово характерно для BRCM, а не для DOCSIS, и занимает несколько последних байтов в преамбуле.

Процент может быть оценен путем взятия UnCorrFECBlks / FECBlks � 100. Счетчиком FECBlks являются общие передаваемые Блоки FEC, или хорошие или плохие. Эти выходные данные относятся ко всему домену MAC (все US). Лучше посмотреть на счетчики между заданным периодом времени для наблюдения дельты.

Примечание: Один недостаток собирающей информации FEC с помощью CLI - то, что UnCorFECBlks, CorFECBlks и общий FECBlks не выделены на восходящий.

Для рассмотрения информации FEC на восходящий необходимо использовать OID SNMP. Можно также использовать команду show cable hop для просмотра исправимых или неисправимых ошибок FEC на восходящем порту, но не общее число блоков FEC.

ubr7246# show cable hop

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream    Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port        Status     Rate Poll   Poll   Poll   Thres Period FEC     FEC
                       (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0 21.810 MHz 1000 0      10     0%     75%   15     2664305 3404
Cable6/0/U1 admindown  1000 * * *   frequency not set   * * * 0       0
Cable6/0/U2 10.000 MHz 1000 * * *set to fixed frequency * * * 0       0

Примечание: Команда clear counters сбрасывает только счетчики show interface и show cable hop, но не show controllers. Управляющие счетчики могут быть сброшены только в случае перезапуска CMTS или выключения и включения питания интерфейса с помощью следующей команды:

ubr# cable power off slot/card

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

Совет: Если счетчик Uncorr инкрементно увеличивается намного быстрее, чем счетчик Поправки, то проблема могла быть отнесена к импульсному шуму. Если счетчик Поправки инкрементно увеличивается как быстро (или быстрее, чем) счетчик Uncorr, то это, вероятно, отнесено к AWGN, или это - установившаяся проблема входящих данных как диапазон частот для личной связи (CB), коротковолновое радио, искажение общего пути (CPD), и т.д.

Как получить счетчики FEC через SNMP

Эти три OID SNMP от файла SNMP MIB DOCS-IF-MIB используются, чтобы собрать и проанализировать ошибки FEC (неошибочный, исправленный, и неисправимый FEC — также см. Приложение):

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

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

  • Cx = docsIfSigQUnerroreds во время x

  • Ecx = docsIfSigQCorrecteds во время x

  • Eux = docsIfSigQUncorrectables во время x

% Корректируемый = [(Ec1Ec0) / [(Eu1Eu0) + (Ec1Ec0) + (C1C0)]] * 100

% Неисправимый = [(Eu1Eu0) / [(Eu1Eu0) + (Ec1Ec0) + (C1C0)]] * 100

Примечание: Uncorrectables плюс unerroreds плюс correcteds равняются общему числу кодовых слов (CW; также известный как блоки данных FEC) полученный на этом US, включая все CW, были ли они частью кадров, предназначенных для CMTS. Размер CW определяется с помощью профиля модуляции.

Счетчики FEC на каждый модем

Если пакет US отброшен, он инкрементно увеличивает счетчик FEC Uncorr. Это происходит на физическом уровне. Вы могли бы спросить, как CMTS отличает отброшенный пакет, если он не имеет возможности видеть Идентификатор службы (SID) или адрес источника (уровень 2). Однако SID CM включен в заголовок DOCSIS.

Пример US разорвал:

(preamble) + {(docsis hdr = 6 bytes) + (BPI+, docsis extended hdr = 4 to 7 bytes) + 1500 ethernet + 18 ethernet header} + (guardband)

Все между {и} сложено, вырезано в CW на основе профиля модуляции, тогда 2�T добавлен к каждому CW. Итак, с технической точки зрения, если особое кодовое слово, содержащее SID, отброшено, как CMTS сможет определить, с какого модема оно было отправлено? Один способ достигнуть этого состоит в том, чтобы использовать планировщика CMTS, который знает время, когда определенные, некоторый пакеты поступили бы от определенных модемов.

Можно отобразить перечисленные значения FEC для каждого модема с помощью команды show interface cableport/slot sid sid-number counter verbose. Можно также получить их через SNMP с помощью этих OID:

  • Хорошие кодовые слова, полученные (docsIfCmtsCmStatusUnerroreds)

  • Исправленные кодовые слова, полученные (docsIfCmtsCmStatusCorrecteds)

  • Получены неисправленные кодовые слова (docsIfCmtsCmStatusUncorrectables)

Примечание: Сейчас это относится только к линейным платам MC28U и MC5x20.

ubr7246-2# show interface cable6/0 sid 10 counter verbose

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Sid                            : 10
Request polls issued           : 0
BWReqs {Cont,Pigg,RPoll,Other} : 1, 527835, 0, 0
No grant buf BW request drops  : 0
Rate exceeded BW request drops : 0
Grants issued                  : 1787705
Packets received               : 959478
Bytes received                 : 1308727992
Fragment reassembly completed  : 0
Fragment reassembly incomplete : 0
Concatenated packets received  : 0
Queue-indicator bit statistics : 0 set, 0 granted
Good Codewords rx              : 7412780
Corrected Codewords rx         : 186
Uncorrectable Codewords rx     : 11
Concatenated headers received  : 416309
Fragmentation headers received : 1670285
Fragmentation headers discarded: 17

Это является определенным для этого модема и обновления счетчиков приблизительно каждые 10 секунд.

ubr7246-2# show cable hop cable6/0

Load for five secs: 5%/1%; one minute: 5%; five minutes: 5%
Time source is NTP, 00:17:13.552 UTC Sat Feb 7 2004
Upstream      Port       Poll Missed Min    Missed Hop   Hop    Corr    Uncorr
Port          Status     Rate Poll   Poll  Poll   Thres Period  FEC     FEC
                         (ms) Count  Sample Pcnt   Pcnt  (sec)  Errors  Errors
Cable6/0/U0   23.870 MHz 1000 0      10     0%     75%   15     186     12

Заметьте, что команда show cable hop сообщает о еще одном Uncorr FEC errors. Возможной причиной ошибки является потеря кодового слова, принадлежащего другому модему.

Было бы содержательно видеть график для каждого СМ ошибок FEC путем опроса MIB и использования Multi-Router Traffic Grapher (MRTG) или другого программного обеспечения, таких как BT Cisco. Это могло использоваться, чтобы видеть, имеют ли определенные модемы плохую задержку группы, микроотражения, и т.д. Это было бы чем-то, что только влияет на определенный модем.

Счетчики восходящих пакетов

Другая команда, которая перечисляет ошибки, является командой show interface cable5/1/0 upstream. Это - пакеты, которые отличаются от CW FEC. Пакет мог состоять из многих CW.

ubr10k# show interface cable5/1/0 upstream

Load for five secs: 4%/0%; one minute: 5%; five minutes: 5%
Time source is NTP, 03:53:43.488 UTC Mon Jan 26 2004
Cable5/1/0: Upstream 0 is up
     Received 48 broadcasts, 0 multicasts, 14923 unicasts
     0 discards, 32971 errors, 0 unknown protocol
     14971 packets input, 72 uncorrectable
     4 noise, 0 microreflections
     Total Modems On This Upstream Channel: 12 (12 active)

Определения терминов:

  • broadcasts — Полученные широковещательные кадры.

  • multicasts — Полученные многоадресные кадры.

  • unicasts — Полученные одноадресные фреймы.

  • discards — Только инкременты на линейной плате MC5x20S. Перечисляет пакеты, от которых сбрасывают из-за различных состояний ошибки, которые являются определенными для карты, не для фактического кадра.

  • errors — Общее количество целого диапазона ошибок, многие из которых не имеют значения. Ошибки, подсчитываемые этим значением, являются ошибками плат на основе BCM3210, таких как MC16C и MC28C:

    • Количество выделенных восходящих слотов, где преамбула и Уникальный Word не были получены должным образом.

    • Количество полученных неисправимых кадров.

    • Коллизии в пропускной способности “запрашивают” возможности.

    • Коллизии в слотах “запроса/данных” (эти типы слотов не происходят на Cisco CMTSs).

    • Поврежденные кадры, полученные во время пропускной способности, “запрашивают” возможности.

    • Поврежденные кадры получены во время слотов “запроса/данных”.

    • Количество поврежденных ранжированных запросов.

    Для ОСНОВАННЫХ НА JIB линейных плат как MC5x20 и MC28U:

    • Восходящие ошибочные фреймы, которые по какой-то причине не классифицированы как ошибочные HCS или CRC.

    • Восходящие кадры с проблемами HCS.

    • Восходящие кадры с CRC-ошибками.

    • Получены неисправимые кодовые слова.

    • Коллизии в IUC запроса полосы пропускания.

  • неизвестный протокол кадров получило, которые не были IP, Протоколом ARP или Протоколом PPPoE. Этот счетчик также включает кадры с неправильно сформированными заголовками DOCSIS или недопустимыми опциями заголовка.

  • вход пакетов broadcasts, multicasts и unicasts.

  • uncorrectable — Общее число кадров, которые имели по крайней мере один неисправимый CW FEC в них. This field shows N/A for the MC5x20 and 28U. Use the Uncorr FEC Errors column in show cable hop output instead, to get an idea about uncorrectable errors.

  • noise — Для основанных на BCM3210 карт как MC16C и MC28C, это - количество поврежденных кадров, полученных в пропускной способности “запрос” или “располагающиеся” интервалы. Из-за этого данное число становится поднабором поднабором чисел в ошибках.

    • Поврежденные кадры, полученные во время пропускной способности, “запрашивают” возможности

    • Поврежденные кадры получены во время слотов “запроса/данных”.

    • Количество поврежденных ранжированных запросов.

    Для ОСНОВАННЫХ НА JIB карт как MC5x20 этот счетчик не инкрементно увеличивается вообще.

  • microreflections — Количество микроотражений; всегда установленный к 0.

errors и счетчики noise только считают поврежденные кадры; они также считают вещи как коллизии запроса исходного ранжирования и коллизии запроса полосы пропускания. So, an incrementing noise counter does not always mean that there is a problem. Это могло бы просто означать, что клиент имеет много модемов, пытающихся прибыть онлайн, или имеет модемы, пытающиеся сделать большие передачи (приводящий к большему количеству коллизий упомянутый). Счетчик шума – это подмножество счетчика ошибок, поскольку шум включает три последних компонента счетчика ошибок.

Заключение

Через опыт и лабораторное испытание, сделанное Advance Services Cisco и группой Мгновенного ответа, это несколько наблюдений относительно FEC и низкой производительности восходящего канала:

  • Присутствие некорректируемых ошибок FEC является хорошим критерием, когда шум достигает недопустимого уровня или когда пакеты конфликтуют друг с другом по причине плохой синхронизации или плохого разделителя головного узла, или изоляции объединяющего блока. Относительно последнего пакет, предназначенный для одного входного порта CMTS, “протекает” на другой восходящий из-за плохой изоляции.

  • Значительное увеличение неустранимых ошибок FEC приводит к проблемам качества голосовой связи.

  • Устранимые ошибки FEC замечены как уровень шума, увеличен. Устранимые ошибки FEC не приводят к отбрасыванию пакета или низкому качеству голосовой связи, пока нет никаких сопроводительных неустранимых ошибок FEC.

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

От предыдущих наблюдений ясно, что опрос CMTS для неустранимых ошибок FEC ценен. Передача голоса поверх IP (VoIP) по кабелю особенно чувствительна к неисправимым ошибкам FEC. Если процент от неустранимых ошибок FEC достаточно высок, то проблемы качества голосовой связи испытаны, тогда как можно было бы только минимально влиять на данные IP.

Наконец, если Чтение SNR микросхемы US вводит в заблуждение, когда быстрые переходные ухудшения RF представлены (как сообщили ранее), но неустранимые ошибки FEC все еще происходят, устраняние проблемы может стать значительно более сложным.

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

Рисунок 3 – SNR и ошибки FEC в течение долгого времени

http://www.cisco.com/c/dam/en/us/support/docs/broadband-cable/radio-frequency-rf-hybrid-fiber-coaxial-hfc/49780-return-path-monitor-3.gif

В то время как нижний график указывает на плохие Чтения SNR в одинаковом экземпляре своевременно, первый график отображает неисправимое и процент устранимых ошибок FEC. Быстрая проверка восходящей в цифровой форме модулированной несущей на анализаторе спектра (таком как HP8591C Agilent), вероятно, показала бы шум in-channel в довольно высоких уровнях. Восходящие проблемы RF сущности импульсного соединения могут быть подтверждены с помощью стороннего тестового оборудования (такого как Hukk CM1000 — обращаются к Вебу - узлы/URL Sunrise Telecom leavingcisco.com— или Acterna DSAM), который может измерить восходящий коэффициент блочных ошибок (подобный BER). Это проверило бы, что проблема RF, вероятно, существует, даже когда Чтение SNR US, кажется, хорошо.

Практический результат - то, что, если Чтение SNR US, кажется, хорошо тогда, автоматически не предполагают, что RF в порядке. Немного исследования с соответствующим тестовым оборудованием могло бы потребоваться, чтобы определять точно, что продолжается в домене RF. Разногласия вполне вероятны, что диапазон радиочастот не является столь чистым, как был сначала принят.

Приложение

Этот раздел детализирует параметры восходящего потока для мониторинга.

Процент восходящего потока, допускающего прямое исправление ошибок без требования повторения передачи (FEC)

Описание

Процент CW с неустранимыми ошибками, полученных по этому каналу. Это включает все CW, независимо от того, являются ли они частью кадров, предназначенных для этого устройства.

Формула

%Correctable = [(Ec1Ec0) / [(Eu1Eu0) + (Ec1Ec0) + (C1C0)]] * 100

  • C = docsIfSigQUnerroreds

  • EC = docsIfSigQCorrecteds

  • Eu = docsIfSigQUncorrectables

Правило Сети

Значения> 2.5% полученных пакетов выделены желтые.

Значения> =5% полученных пакетов являются полужирным шрифтом красного цвета.

Информация Сети

Процент входных CW с исправимыми ошибками FEC, по отношению к общему количеству CW, полученных этим интерфейсом. Предложено, чтобы это соотношение было ниже 5% всех входных CW.

Подробные сведения

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

Процент неисправимых ошибок FEC в восходящем канале

Описание

Процент CW с неустранимыми ошибками, полученных по этому каналу. Это включает все CW, независимо от того, являются ли они частью кадров, предназначенных для этого устройства.

Формула

%Uncorrectable = [(Eu1Eu0) / [(Eu1Eu0) + (Ec1Ec0) + (C1C0)]] * 100

  • C = docsIfSigQUnerroreds

  • EC = docsIfSigQCorrecteds

  • Eu = docsIfSigQUncorrectables

Правило Сети

Значения> 0.5% полученных CW выделены желтые.

Значения> =1% полученных CW являются полужирным шрифтом красного цвета.

Информация Сети

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

Примечание: Определенные сервисы “в реальном времени”, такие как VoIP, могут потребовать более строгого мониторинга. 1%-е неисправимое значение FEC могло бы все еще быть достаточной потерей пакета для порождения проблем качества голосовой связи, в зависимости от того, если потеря разорвана или случайна.

Подробные сведения

DOCS-IF-MIB
docsIfSigQUnerroreds       .1.3.6.1.2.1.10.127.1.1.4.1.2
      Codewords received on this channel without error.
      This includes all codewords, whether or not they
      were part of frames destined for this device.

docsIfSigQCorrecteds       .1.3.6.1.2.1.10.127.1.1.4.1.3
      Codewords received on this channel with correctable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

docsIfSigQUncorrectables   .1.3.6.1.2.1.10.127.1.1.4.1.4
      Codewords received on this channel with uncorrectable
      errors. This includes all codewords, whether or not
      they were part of frames destined for this device.

SNR для восходящего потока

Описание

SNR для данного канала. В CMTS, описывает средний сигнал к шуму канала передачи от клиента.

Формула

SNR = docsIfSigQSignalNoise / 10

Правило Сети

Значения <27 дБ выделены желтые.

Значения <23 дБ являются полужирным шрифтом красного цвета.

Информация Сети

DOCSIS задает минимальный CNR (в цифровой форме эквивалентный SNR) 25 дБ. В зависимости от восходящего настроенного профиля модуляции (QPSK или с 16 QAM), минимальный SNR 25 дБ, возможно, должен быть увеличен.

Подробные сведения

ubr7246vxr# show controller cable3/0 upstream 0

 Cable3/0 Upstream 0 is up
  Frequency 25.392 MHz, Channel Width 3.200 MHz, QPSK Symbol Rate 2.560 Msps
  Spectrum Group is overridden
  BroadCom SNR_estimate for good packets - 26.8480 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2035
  
DOCS-IF-MIB
docsIfSigQSignalNoise      .1.3.6.1.2.1.10.127.1.1.4.1.5
      Signal-to-Noise ratio as perceived for this channel.
      At the CM, describes the Signal-to-Noise of the downstream
      channel.  At the CMTS, describes the average Signal-to-Noise
      of the upstream channel.

Пример извлечения идентификаторов объектов для модемных счетчиков FEC на линейной плате MC28U или 5x20

ubr7246# show cable modem 10.200.100.115

MAC Address    IP Address    I/F        MAC    Prim  RxPwr   Timing  Num  BPI
                                        State  Sid   (dBmV)  Offset  CPE  Enb
0005.5e25.bdfd 10.200.100.115  C6/0/U0  online 50     0.50   2077    0    N

ubr7246# show interface cable 6/0 sid 50 counters verbose | incl Sid|Codeword

Sid                            : 50
Good Codewords rx              : 7580
Corrected Codewords rx         : 0
Uncorrectable Codewords rx     : 2

Для обнаружения счетчиков Кодового слова этого модема сначала необходимо получить две части информации:

  • Индекс интерфейса SNMP для кабельного интерфейса 6/0.

  • docsIfCmtsServiceNewCmStatusIndex модема.

Найдите ifIndex кабеля 6/0 с этой командой:

% snmpwalk -cpublic 172.18.73.167 ifDescr | grep Cable6/0

RFC1213-MIB::ifDescr.10 = STRING: "Cable6/0"

!--- ifIndex of cable 6/0 is "10".

RFC1213-MIB::ifDescr.36 = STRING: "Cable6/0-upstream0"
RFC1213-MIB::ifDescr.37 = STRING: "Cable6/0-upstream1"
RFC1213-MIB::ifDescr.38 = STRING: "Cable6/0-upstream2"
RFC1213-MIB::ifDescr.39 = STRING: "Cable6/0-upstream3"
RFC1213-MIB::ifDescr.40 = STRING: "Cable6/0-downstream"

Найдите docsIfCmtsServiceNewCmStatusIndex модема с SID 50 на интерфейсе с ifIndex 10 (кабель 6/0) с этой командой:

% snmpwalk -cpublic 172.18.73.167 docsIfCmtsServiceNewCmStatusIndex.10.50

DOCS-IF-MIB::docsIfCmtsServiceNewCmStatusIndex.10.50 = INTEGER: 983090

Теперь, когда у вас есть docsIfCmtsServiceNewCmStatusIndex модема (983090), можно найти эти счетчики FEC:

  • Хорошие кодовые слова, полученные (docsIfCmtsCmStatusUnerroreds)

    % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUnerroreds.983090
    
    DOCS-IF-MIB::docsIfCmtsCmStatusUnerroreds.983090 = Counter32: 8165
    

    Примечание: Значение счетчика Unerroreds увеличилось с момента подачи команды show interface cable.

  • Исправленные кодовые слова, полученные (docsIfCmtsCmStatusCorrecteds)

    % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusCorrecteds.983090
    
    DOCS-IF-MIB::docsIfCmtsCmStatusCorrecteds.983090 = Counter32: 0
    
  • Получены неисправленные кодовые слова (docsIfCmtsCmStatusUncorrectables)

    % snmpget -cpublic 172.18.73.167 docsIfCmtsCmStatusUncorrectables.983090
    
    DOCS-IF-MIB::docsIfCmtsCmStatusUncorrectables.983090 = Counter32: 2
    

Связанные обсуждения сообщества поддержки Cisco

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


Дополнительные сведения


Document ID: 49780