Poprawna odpowiedź wskazuje przedział bitowej stopy błędów BER na poziomie 10^-13 ÷ 10^-12 dla pojedynczego urządzenia w sieci szerokopasmowej. Taki rząd wielkości jest przyjmowany w praktyce telekomunikacyjnej jako granica, przy której transmisja jest jeszcze uznawana za wysokiej jakości, ale jednocześnie realna do uzyskania w typowych warunkach eksploatacyjnych. W standardach dla sieci szerokopasmowych, czy to SDH, DWDM, czy nowoczesnych systemów Ethernetowych klasy operatorskiej, zakłada się, że pojedynczy element toru transmisyjnego (np. jeden wzmacniacz optyczny, jedno urządzenie multipleksera, jeden odcinek linii) nie może wprowadzać zbyt dużej liczby błędów, bo takich elementów po drodze jest zwykle kilka lub kilkanaście i błędy się kumulują. Moim zdaniem dobrze to widać na prostym przykładzie: jeśli masz 10 urządzeń po drodze, a każde miałoby BER rzędu 10^-9, to końcowa jakość byłaby dramatyczna – praktycznie co jakiś czas leciałyby pakiety z błędami, co rozwala aplikacje czasu rzeczywistego typu VoIP, IPTV czy transmisje korporacyjne. Dlatego w sieciach operatorskich dąży się do BER na poziomie 10^-12 lub lepszym na urządzenie. W testach akceptacyjnych urządzeń szerokopasmowych stosuje się generatory i analizatory wzorcowych sekwencji bitowych (PRBS), które „przepychają” przez urządzenie ogromną liczbę bitów i zliczają błędy. Jeżeli po przesłaniu np. 10^13 bitów liczba błędów nie przekracza założonego progu, uznaje się, że urządzenie spełnia wymagania. W praktyce przekłada się to na stabilną pracę usług takich jak transmisje wideo w wysokiej rozdzielczości, synchronizacja danych między serwerowniami, czy łącza operatorskie między węzłami sieci szkieletowej. Dobra praktyka mówi też, że im wyższa przepływność (10 Gb/s, 100 Gb/s i więcej), tym ostrzejsze wymagania na BER, bo pojedynczy błąd ma większy wpływ na wolumen danych. Ten przedział 10^-13 ÷ 10^-12 jest więc takim sensownym kompromisem między wymaganiami jakościowymi a kosztami i złożonością sprzętu.
W sieciach szerokopasmowych intuicja często podpowiada, że „im mniejszy BER, tym lepiej” i to prawda, ale tylko do pewnego stopnia. Trzeba patrzeć nie tylko na samą liczbę, ale też na realne możliwości technologii, koszty i to, jak wiele urządzeń jest w całym torze transmisyjnym. Zbyt optymistyczne lub zbyt luźne założenia co do bitowej stopy błędów prowadzą do błędnych wniosków projektowych. Bardzo niskie zakresy typu 10^-15 ÷ 10^-14 wyglądają na pierwszy rzut oka atrakcyjnie, bo przecież oznaczają ekstremalnie rzadkie błędy. Problem w tym, że dla pojedynczego urządzenia szerokopasmowego jest to poziom typowy raczej dla bardzo zaawansowanych, specjalistycznych zastosowań (np. laboratoryjne łącza optyczne, bardzo krótkie odcinki w kontrolowanych warunkach), a nie dla typowego elementu w dłuższym łańcuchu sieci operatorskiej. Wymaganie aż tak niskiego BER od każdego urządzenia podnosiłoby drastycznie koszt sprzętu i komplikowało projekt, a zyski jakościowe byłyby w normalnych sieciach niewspółmierne do nakładów. Z drugiej strony zakresy 10^-14 ÷ 10^-13 czy 10^-12 ÷ 10^-11 są charakterystyczne raczej dla granicy akceptowalności lub dla starszych, mniej wymagających środowisk. W takich wartościach błędy pojawiają się już zbyt często, zwłaszcza jeśli zsumujemy wkład wielu urządzeń pośrednich. Typowy błąd myślowy polega tu na patrzeniu na jedno urządzenie w oderwaniu od całej ścieżki transmisyjnej. Ktoś widzi, że 10^-11 oznacza „tylko” jeden błędny bit na 100 miliardów i wydaje się to mało. Ale przy przepływnościach rzędu wielu gigabitów na sekundę i kilku, kilkunastu urządzeniach w torze, takie błędy zaczynają być widoczne jako spadek jakości usług, retransmisje, rosnące opóźnienia. Z mojego doświadczenia widać to szczególnie przy usługach IPTV i transmisjach wrażliwych na opóźnienia – zbyt wysoki BER przekłada się na zacięcia obrazu, artefakty i ogólnie słabą jakość. Dlatego standardy i dobre praktyki sieci szerokopasmowych ustawiają dla pojedynczego urządzenia przedział 10^-13 ÷ 10^-12 jako rozsądny kompromis. Zbyt restrykcyjne lub zbyt luźne wartości z pozostałych odpowiedzi po prostu nie pasują do typowego, realnego środowiska operatorskiego i nie uwzględniają kumulacji błędów na całej długości toru.