Jak to jest z interoperacyjnością w sieciach GPON?

Oszczędności wymagają wiedzy

Po co w ogóle zamawiać ONT na własną rękę? Dla elastycznego zarządzania dostawami sprzętu. Sama możliwość uruchomienia terminali „3rd party” powoduje, że aktualny dostawca jest bardziej przystępny.

Jeżeli jednak chcemy mieć nad ONT pełną kontrolę, to wymagać to będzie sporo pracy.

Będą potrzebne:

  • kompetencje,
  • kompetencje,
  • kompetencje,
  • ...
  • dostawca sprzętu z doświadczonym działem R&D (lub doświadczony dział R&D u zewnętrznego dostawcy oprogramowania).

Do swoich czipsetów producenci najczęściej oferują rozbudowane SDK (ang. software development kit), umożliwiające stworzenie własnego oprogramowania, co nie zmienia faktu, że to nadal sporo pracy dla programistów.

Należy się zastanowić nad preferowanym sposobem zarządzania ONT-ami. W przypadku prostych SFU (ang. single family unit) nie jest to rozwiązania zbyt skomplikowane. Ale już w przypadku HGU (ang. home gateway unit), provisioning jest już zaprojektowany przez producenta OLT – czyli tak, żeby to jemu przede wszystkim było wygodnie. I żeby było inaczej, iż u konkurencyjnych dostawców.

Znanych dzisiaj problemów z interoperacyjnością urządzeń GPON należy się spodziewać także w przyszłości. Dlatego warto zbierać doświadczenia.

Nie da się ukryć, że wysoki poziom integracji elementów systemu w zamkniętych rozwiązaniach powoduje naturalną chęć do korzystania z nich, co niestety zamyka w systemach typu vendor lock-in.

Jak to robi najwięksi?

Odpowiedź jest krótka – przede wszystkim wszystko upraszczają. Z poziomu OLT konfiguruje się tylko podstawowe funkcje uruchomienia komunikacji HGU z serwerem TR069 [protokół zarządzania urządzeniami sieciowymi – red.]. I nic więcej.

Jeżeli jednak celem jest, aby pewne funkcje były konfigurowalne z OLT poprzez OMCI [standard zestawu komunikatów do provisioningu usług – red.], to wymaga sporo detektywistycznej pracy w tym również badań z obszaru inżynierii odwrotnej. Może to dać sporo satysfakcji, ale przede wszystkim daje bezcenną wiedzę i pozwala budować kompetencje. W ten między innymi sposób kompetencje nabywaliśmy w naszym własnym LeoLabs, rozwiązując problemy zafundowane nam przez dostawców sprzętu (Calix z Ericssonem). I odnieśliśmy sukces, a przy okazji nabyliśmy kompetencje, oraz okazję tworzenia własnego oprogramowania na ONT (dzisiaj mamy pełen magazyn terminali różnych dostawców z dużą liczbą płyt ewaluacyjnych, na których testujemy różne warianty oprogramowania).

Chciałbym, niejako przy okazji, odnieść się do wypowiedzi Radosława Zięby z Fibrain, cytowanego przez TELKO.in w artykule „Hurt to trudny biznes na rynku ISO”, w którym stwierdził, że urządzenia marki Dasan wspierają interoperacyjność. Z całą odpowiedzialnością i powagą mogę stwierdzić, że tak nie jest, i że Dasan nie trzyma się ściśle specyfikacji G.984/G.988. Stąd rozliczne kłopoty i próby dojścia, dlaczego nie działa aktualizacja oprogramowania ONT producentów innych niż Dasan z poziomu OLT tego producenta za pośrednictwem OMCI (dla nas to już nie jest tajemnica).

Czy XGS-PON będzie sprawiał podobne problemy?

Obawiam się, że tak. Będzie lepiej, ale jeszcze nie dobrze. Dużym producentom (czegokolwiek by nie deklarowali) po prostu nie zależy na pełnej interoperacyjności urządzeń sieciowych. Wszystkie więc wypracowywane dzisiaj doświadczenia z optymalizacją rozwiązań różnych producentów dla GPON w przyszłości będzie można (i, niestety, trzeba) przenieść na XGS-PON. W nagrodę będą konkretne oszczędności.

AUTOR

CTO we własnej firmie telekomunikacyjnej z rejonu Rybnika. Pasjonat telekomunikacji. Członek rady programowej konferencji PLNOG. Od wielu lat zawodowo prowadzi szkolenia z zakresu telekomunikacji. Absolwent Politechniki Śląskiej w Gliwicach na kierunku Elektronika-Telekomunikacja.