Wzrost zainteresowania usługami na żądanie, takimi jak: time-shift TV, VOD i nPVR, postawił przed operatorami nowe wyzwanie związane z gwałtownym wzrostem ilości strumieni w sieciach dystrybucyjnych. Edgeware opracował unikalny serwer Orbit 2x, który pomaga rozwiązać problem przepustowości sieci szkieletowej. Jego wyjątkowe cechy to:
Serwer posiada dwa porty optyczne XFP 10GBASE-SR/LR/ER, przeznaczone do streamingu oraz jeden port elektryczny 10/100/10 00BASE-T, RJ45, służący do zarządzania. Na początku problemem może się okazać transmisja 10GBASE, która nie jest jeszcze zbyt popularna. Większość sieci jest zbudowanych w technice 1GBASE. Dlatego serwer powinien być podłączony do Switcha posiadającego zarówno porty 10GBASE, jak i 1GBASE. Switch natomiast powinien się znajdować w miejscu, z którego istniejąca sieć rozchodzi się gwiaździście.
W momencie wdrażania usługi VOD, do streamingu można używać portu 10/100/1000BASE-T, RJ45, przeznaczonego do zarządzania.
Maksymalna sumaryczna przepływność strumieni wyjściowych dla Orbit 2x wynosi 20Gbps. Odpowiada to kolejno:
Natomiast maksymalna jego pojemność to 3TB (6TB w ostatnim kwartale 2008 roku), co odpowiada:
Upload kontentu VOD na serwer odbywa się za pomocą transmisji ftp. Natomiast serwery między sobą wykorzystują protokół RSTP. Maksymalna szybkość ściągania danych to 1,7Gbps. W celu realizacji usług nPVR i time shift TV w Orbit 2x została zaimplementowana funkcja nagrywania multicastów. Umożliwia ona zapis strumieni o łącznej przepływności nieprzekraczającej 1,2Gbps. Nagrywane strumienie multicastowe są dostępne w postaci unicastów z opóźnieniem nieprzekraczającym 1 sekundy. Zatem abonent nagrywający daną pozycję może ją natychmiast odtwarzać. Aby wydajniej gospodarować miejscem dostępnym na serwerach, multicasty mogą być nagrywane bezpośrednio na repozytorium dyskowe. Umożliwia to Edgeware Ingest Server. Jest to standardowy serwer linuksowy zawierający podobne oprogramowanie co Orbit 2x. Aplikacja ta jest szczególnie pomocna przy realizacji time shift TV.
Istnieją dwa modele nagrywania. Pierwszy z nich jest zrealizowany lokalnie. Gdy serwer otrzymuje zadanie nagrywania, rozpoczyna je automatycznie bez informowania reszty systemu o wykonywanej operacji. Jest to rozwiązanie dobre dla małych sieci, gdyż nie wymaga skomplikowanej konfiguracji. W przypadku większych systemów nagrywanie powinno być realizowane centralnie. W tym celu EPG (STB) generuje plik XML, który przesyła do serwera EPG, skąd jest ściągany przez serwery Orbit 2x za pomocą transmisji ftp w określonych interwałach czasowych.
Serwer wymaga dostarczenia plików w formacie MPEG2 Transport Stream. Formaty video w nich zawarte to MPEG2 lub H.246/AVC. Można jednak przekonwertować dowolny format video do formatu akceptowalnego dla serwera Orbit 2x. W tym celu producent zaleca oprogramowanie Converter Studio Pro firmy Elecard.
Kluczową kwestią w sieciach z usługami na żądanie jest przepływność sieci szkieletowej. Przy przesyłaniu serwisów telewizyjnych na żywo korzystamy z transmisji broadcast lub multicast. Łatwo zatem policzyć, iż maksymalna przepływność w szkielecie będzie zależała wprost proporcjonalnie od liczby emitowanych kanałów telewizyjnych. Co oznacza, że przy 60 serwisach SD (przepływność ok. 6 Mbps) maksymalna przepustowość naszej sieci powinna wynosić ok. 360 Mbps. Dużo trudniej oszacować przepustowość szkieletu, gdy dochodzą usługi na żądanie, przesyłane do abonenta za pomocą transmisji unicast, ponieważ w tym samym czasie nie wystąpią w sieci dwa jednakowe strumienie video na żądanie, a ich liczba będzie się powiększała wraz z żądaniami wysyłanymi przez klientów. Dlatego w miarę wzrostu liczby abonentów należy rozbudowywać system, dokładając serwery brzegowe. System Convoy został zaprojektowany w celu stworzenia sieci hierarchicznej, w której serwery z najpopularniejszymi pozycjami znajdowałyby się najbliżej abonentów. Jest on integralną częścią każdego serwera Orbit 2x i nie wymaga centralnej konfiguracji. Serwery brzegowe z kierowanych do nich zapytań generują statystyki popularności. Na ich podstawie podejmują decyzję, czy dany film należy ściągnąć, tak aby znajdował się bliżej klienta. W tym samym momencie, jeśli jest taka potrzeba, zostaje skasowana najmniej popularna pozycja w celu zwolnienia pamięci. Jeżeli żądany kontent nie jest dostępny na danym serwerze brzegowym i jego popularność jest niewielka, to serwer ten wyśle informacje za pomocą protokołu RSTP do serwera centralnego, aby rozpoczął streaming do klienta. Ten sam mechanizm może być również wykorzystany pomiędzy serwerem centralnym i zewnętrznym repozytorium dyskowym. W momencie otrzymania żądania kontent jest automatycznie ściągany z repozytorium dyskowego za pomocą transmisji ftp. Nie mają wtedy znaczenia charakterystyki popularności takiego filmu. Kontent jest stremowany do klienta już w trakcie ściągania. Nie trzeba zatem czekać do zakończenia tej operacji, zaś abonent może rozpocząć oglądanie automatycznie po wysłaniu żądania. Jak widać, wszystkie decyzje w systemie Convoy są podejmowane lokalnie, zatem jest on bardzo niezawodny i prosty w implementacji.