ad hw - nez klicenka ve WL500 mozna staci klicenka primo v raspberry nebo jinem hw, na kterem bezi sw pro d-star + pppd? Raspberry muze mit problem s napajenim (starsi verze ma slabe pojistky a klicenka si zpravidla bere vic, novejsi verze jednu klicenku utahne v poradku). Klicenku pripadne umim sehnat za rozumny obnos ("bazar" zarizeni vracenych zakaznikem ve zkusebni dobe, zrevidovanych a poskytnutych dale k prodeji se zkracenou zarukou za zajimavou cenu - tusim kolem 77,-)

Ahoj,

rozhodně to neklapne, po vyčerpání FUPu 200 MB to bude prakticky nepoužitelné. Těch 16 kb/s i kdyby bylo garantovaných, jakože z principu ani nemůže být, to nikdy korektně nepřenese, nehledě na latence ve 2G síti. Prošel jsem si reálným testováním, kdy se zvažovalo jestli DMR na jedné exponované lokalitě připojit via 2G/3G nebo CDMA. 3G samozřejmě nedostupné, u 2G i přes signál na úrovni -60 dBm (lokální site), to nebylo schopno pracovat a to se neuplaťnoval navíc žádný FUP a bylo to na EDGE, které by teoreticky mohlo valit cca 200 kb/s. Naprosto nepoužitelné v reálném provozu. CDMA naopak ve spojení s DMR plně použitelné a několik měsíců to šlapalo. U D-STARu nevím jak s latencí, ale DMR si to umí slušně nabafrovat a není to tedy na tak háklivé. A to víme jaké latence jsou na CDMA... Po odlivu zákazníků z CDMA je ta síť slušně použitelná, než se zrusí. Problém je, že nelze obdržet fixní veřejnou IP a navíc to hlavní, že je to za firewallem O2, takže nemáš možnost pracovat s NATem a porty. Což je u D* klíčové. A balit hlas do VPN je nesmysl, jednak se to nedělá a vznikala by další datová režie na VPN tunel. IPSec je klasikcý případ, s ohledem na provoz v mobilní síti. A další věc, otázka dostupnosti na lokalitu, vyžadovalo by to slušné, nejlépe průmyslové CPE (router) pracující s mobilním wan rozhraním a HW watchdogem. Dávat tam nějaký stařičký soho Asus, typu WL s USB donglem, je nesmysl, jen riziko.

Zdravim,

tak jsem to vyzkousel co je realne s mobilnim pripojenim a d-star s pripojenim na ip reflector. Vysledek.... neni to prilis stabilni, nicmene pouzitelne to je. Tohle je sestava, kterou jsem pouzil, telefon podporoval EDGE, pripojeni v me lokalite bylo ve vecernich hodinach ve meste cca 85kbit tam i zpet.

mereni provadeno primo na ip rozhrani ppp, up4dar pripojen za NAT za pouziti RouterBoardu, GSM telefon standartni na USB, v rezimu hloupeho modemu. Trochu problemy, nez se mi to podarilo s tim Mikrotikem rozchodit.

Zde je stav v "Idle" rezimu, up4dar se dotazuje cca co 6sec ip reflectoru, ans/req v pomeru 700/700bps

Tady pripojen na DCS019 Z (echo kanal), 30s TX (bez odpovedi, zrejme neopakuje tak dlouhou relaci), pak dve relace po sobe (7s a 10s) ve spicce je to 51kbps jak TX tak RX. Zkousel jsem to pak nekolikrat, hlas je obcas rozsekany, nektere relace prosly bez problemu.

Mobilni pripojeni otestovano "zatezovym" pingem na dcs019.xreflector.net s odezvou 200 - 250ms, stejna odezva byla i na DNS operatora. Traffic v IP reflectoru cca 50kbps me pripada celkem dost velky a srovnatelny se SIP ve VoIP sitich.
Po cca 3 hodinach bezneho vecerniho provozu na DCS019 modem "natocil" cca 6MB in a 5,5MB out, v RX rezimu je poslech bezproblemovy a i 1/2hod. vykecavani proslo bez sebemensich problemu. V TX rezimu to ovsem bylo horsi.

Traffic v IP reflectoru cca 50kbps me pripada celkem dost velky a srovnatelny se SIP ve VoIP sitich.

Protokol DCS je dost rozežraný, jestli se nepletu tak v každém UDP paketu posílá krom 12bajtového Dstar rámce ještě kopii kompletní hlavičky.
Při CSR (gw<->gw) byl průtok cca 25kbit, při Dplus (gw<->REF) cca 30kbit (aspoň co si pamatuju z měření z roku 2011).

Doba od vzniku D* trochu postoupila a kráčí dál a na ceně připojení jestli je datový tok 25 kbps, nebo 50 kbps to již nemá žádný vliv. To že se přenáší hlavička nejen na začátku má také své výhody.

EDGE je opravdu extrémně nouzové řešení. Ani tak nejde o velikost datového toku, ale největší problém je s přidělováním zdrojů. Mechanismus na základě kterého síť rozhoduje, kolik timeslotů a jaké modulační schéma se použije (CS-1 až MCS-10 teoretické maximum 236,8 kbps) pracuje s okamžitým datovým tokem a dalšími parametry jako kvalita signálu, zatížením buňky a.t.d. Díky tomu, že je datový tok relativně malý, tak dochází k stálému přepínaní počtu TS, naplní buffer přidají se TS odteče to najednou, pak se zase ubere a počet TS se zmenší a.t.d. Každá rekonfigurace má nějaký procesní čas a negativně se to projeví v jitteru a v případě byť krátkodobého vytížení buňky (někdo si zrovna klikl na velký obrázek a jsou obsazené všechny volné TS) se nemusí na krátký časový okamžik dostat zpět potřebný počet TS, protože GPRS neumí dělat prioritizaci na základě druhu přenášené informace. V případě HTTP, nebo FTP přenosu by se to projevilo lehce prodlouženou odezvou natažení stránky (u FTP třeba ani to ne, protože trvalý přenos dat by dobrovolně žádný TS neuvolnil tak že by k takovéto situaci nedošlo), pro streaming provoz je to smrtelná záležitost, jelikož dojde k výpadku souvislého přenosu hlasu.

U 3G je situace trochu lepší, princip přidělování zdrojů je o dva až tři řády rychlejší nicméně stejně jsou všechny TCP rámce v kategorii Best Effort t.j. NON-GBR. Toto bude možné plně využívat až u LTE, které má řízení QoS (Quality of Service) na mnohem vyšší úrovni. Docela srozumitelně je to popsané třeba zde:
http://www.roke.co.uk/resources/white-papers/0485-LTE-Radio-Bearer-QoS.pdf
http://www.ixiacom.com/pdfs/library/white_papers/policy_management.pdf