Hirdetés
- Felháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
Új hozzászólás Aktív témák
-
dchard
veterán
"Hozzá kell tegyem hogy egy cellában csak 10 ember mért, ezért jöhettek ki ilyen eredmények"
Kizárt. Te a 60 megabitet üres szektoron mérted egymagad úgy, hogy a cella szájában voltál. Ha tényleg 10-en mértetek volna azonos körülmények között egyszerre, akkor 10 mega se jött volna ki belőle. Ez persze nem baj, sőt: így törvényszerű.
Jó is, hogy eszembe juttatod: ugye senki nem felejtette el, hogy az LTE hálózat jelenleg jóformán üres, és egy üres hálózaton ugye nem nehéz virítani (akik az elejétől kezdve HSPA-znak, azok tudják, ugyan ez volt 2-3 évvel ezelőtt). Majd amikor annyi LTE előfizető lesz, mint HSPA, akkor nem ilyen eredmények fognak majd kijönni. Főleg 10MHz-en nem...
A pingnek jobban örülnék, ha inkább 25 lenne, mint 50-en egy üres hálózaton. HSPA+ hálózaton mértem már tartósan 30-40ms közötti késleltetést, ahhoz képest nem túl látványos az előrelépés.
Abban egyet értünk, hogy a Huawei stickekkel tojást lehet sütni.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Coolmat
őstag
Fél off: várjuk az LTE tesztelőket ebbe a topikba!
Érdemleges infó: a tegnapi LTE teszten 10-11 helyszínt bejárva mindenhol 25-55 Mbit/s között mértünk lefelé, 15-30 között felfelé, a rekord a Millenáris Parkban volt 60 Mbit/s fölötti letöltéssel. Hozzá kell tegyem hogy egy cellában csak 10 ember mért, ezért jöhettek ki ilyen eredmények, mikor már 100-200 klienst kell majd kiszolgáljon egy cella közel sem lesz ilyen rózsás a helyzet szerintem. A ping 25-50 között alakult, kis kompromisszumokkal online játék is élvezhető. A Huawei stick-el pedig fűteni lehet, annyira forró.
-
dchard
veterán
Ezen a ponton nem tudjuk eldönteni, hogy igaza van-e vagy nem. A téma további offolása nélkül kíváncsi lennék rá, hogy van-e műszaki magyarázata arra, hogy 14 kóddal miért ne működne a MIMO egy vivős rendszerben. Ha megkérdeznéd és mondana valamit, privátban szívesen elolvasnám, komolyan.
A Rel7 CQI tábla kimondja, hogy ha 30-at riportol a UE, akkor az bizony 64 QAM és 15 kód. Ennek ellenére amikor több user használta az állomást, láttam a trace-ből, hogy bizony nem 15 kódot kapnak a userek, mert 2-3 maximum 4 konkurens userig jobban megéri kódosztani, mint időosztani. A 64QAm persze stimmelt. a TB size-ra már nem emlékszem.
"Egyébként ezért írtam, hogy jó schedulerrel kikerülhető az, hogy a MIMO elfoglalja az egészet - amíg a MIMO user a jani, abban a TTI-ben senki más nem kap semmit. A köv TTI-ben meg mehet a buli a többieknek. Effektíve átmentünk TDMA-ba, ez van."
Értem a koncepciót, a probléma viszont az, hogy ha egy vivőd van, akkor nem lehet. Azért nem, mert az alapvető működéshez szükséges jelzés csatornák és a bejövő handoverek kezelésére fenntartott minimális kapacitás több mint egy SF16 kódot foglalnak el, így ha egyetlen user sincs a cellán, már nincs 15 szabad kód. Márpedig a jelzéscsatornákkal nem játszhatod el, hogy néhány TTI erejéig nem küldesz rajtuk semmit, hanem bevonod őket a HS-PDSCH poolba. A jelzés csatornák fixen le vannak foglalva.
"SU-MIMO van, és mint olyan single user, tehát 1 frekvencián 1 TTI alatt 1 db user. Akkor meg mi a halálért ne kapna meg minden erőforrást."
Szintén csak educated guess, de szerintem azért, amiért nem kapja meg az összes power-t egyetlen user akkor sem, ha 0-ás vagy 1-es CQI-t riportol (=szar rádiós körülmények között van) és nem kapja meg az összes kódot akkor sem, ha senki nincs a cellán. 3 féle nodeb ütemező van, ezek közül kivétel nélkül mindenki a proportional fairness-t használja, ez pedig nem engedi. Mondjuk úgy, hogy a PF figyelembe veszi azt is, hogy ha egységnyi sebesség növekedésre aránytalan erőforrás-ráfordítás szükséges és ezt megakadályozza. Képzeld el, hogy a UE rossz rádiós körülmények között van, és 0,1,2 CQI-t riportol. Eszerint a nodeb 15 kóddal kitolja neki a 4500 bájtos TB-t? Túl sok erőforrás lenne a nagyon kevés javulásért. Akkor már inkább QPSK 5 kódon MIMO nélkül, és közben más UE-t is ki tud szolgálni.
Tényleg le kéne ülnünk sörözni
Örülök, hogy rád akadtam. 
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
LordX
veterán
Nem akarlak én meggyőzni, a szabvány az, ami mondja. Ha van a leírtaknak másik értelmezésed, akkor hajrá. Én így értelmeztem, a "helyi" rádiós szaki (mármint olyan, aki a NB szoftverét írja) is erősen kiemelte, hogy MIMO-hoz 15x SF16 kód kell.
A tesztre ezek után kíváncsi vagyok.
Egyébként ezért írtam, hogy jó schedulerrel kikerülhető az, hogy a MIMO elfoglalja az egészet - amíg a MIMO user a jani, abban a TTI-ben senki más nem kap semmit. A köv TTI-ben meg mehet a buli a többieknek. Effektíve átmentünk TDMA-ba, ez van.
Erős gondolat, hogy miért is van ez így (színtiszta spekuláció, de azért az educated guess kategória): SU-MIMO van, és mint olyan single user, tehát 1 frekvencián 1 TTI alatt 1 db user. Akkor meg mi a halálért ne kapna meg minden erőforrást. LTE is SU-MIMO, csak ott minden kis hordozó külön számít, 1 frekvencián belül meg nincs CDMA.
A MU-MIMO még nagyon elméleti síkon mozog, és brutális teljesítményű DSP kell hozzá, mindkét oldalon.
-
dchard
veterán
Nem győztél meg. Továbbra is azt gondolom, hogy minimum furcsa lenne, ha egy olyan technológiát, amivel éppen frekvenciát lehet spórolni, ne lehetne bevezetni 1 működő vivővel. Márpedig ha szentírásnak veszem a 15 kódot, akkor ez a helyzet, mivel egy egy vivős élőhálózati cellát egyszerűen nem tudsz felkonfigurálni úgy, hogy 15 szabad kódod maradjon. Arról nem beszélve, hogy 4500 bájtos transport blockot tudod te hol fog a proprtional fairness algoritmus 15 kódon kitolni egyetlen UE-nak... Némiképp ellentmond a tervezési alapelveknek.
A CQI mapping tábla egyébként is maximum értékeket állapít meg. Például attól, hogy a UE 30-as CQI-t riportol, még nem szükségszerűen kell a nodeB-nek 15 kódon küldenie annak az egy UE-nak a cuccost. A moduláció marad, de a coding rate és a használható kódok számát a nodeB dönti el. Simán elófordulhat, hogy van egyszerre két UE-d 30-as CQI-val, ilyenkor egyik sem fog 15 kódot kapni, mivel 3-4 párhuzamos felhasználóig megéri inkább 7-8 vagy 8-7, illetve 5-5-5 arányban kódot osztani, és akkor mindjárt nem lesz igaz, hogy a 30-as CQI-ú userek 15 kódot kapnak.
Végül is azzal, hogy kevesebb kódot kap egy UE, valahol visszafordítható frekire, de attól még a MIMO működési alapelve ugyanúgy érvényesül, csak nem 2x14.4 lesz, hanem 2x9600, 2x7200, 2x3600 és így tovább.
Ki fogom próbálni kevesebb kóddal, de ha működik (nyilván lassabb lesz), meghívsz egy pofa sörre.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
LordX
veterán
A Type A report azt jelenti, hogy MIMO-val akarsz adatot átvinni. Type B esetben nincs MIMO:
"6A.1.2.2 Composite PCI/CQI reporting procedure in case the UE is configured in MIMO mode:
Type B: CQI reports that indicate the supported transport format for a single transmitted transport block according to the current channel conditions assuming that the preferred primary precoding vector as indicated by the PCI value signalled in the same HS-DPCCH sub-frame would be applied at the Node-B for the primary transport block and that no secondary transport block is transmitted."
Ugyanaz a doksi, csak a 10.4.0-s verzió (friss ropogós mai dátummal).
[ Szerkesztve ]
-
dchard
veterán
Már majdnem megijedtem, aztán persze felfedeztem, hogy csak a dual transport block type A CQI reports használata esetén kell valóban 15 kód. Egyébként józan ésszel is belátható, hogy 15 kód a legeslegritkább esetben (értsd: laborban, 1 HS-SCH kóddal, egyetlen készülékkel) lesz szabad egy élő hálózaton. Már elvi szinten sem jön ki a dolog, hiszen 3 darab HS-SCH csatorna a legtöbb éles nodeB-n elengedhetetlen, különben már közepes ügyfélszámnál is torlódni fognak a HSDPA működéséhez elengedhetetlen HS-SCH csatornák, jönnek a sorozatos mac-d failure-ök, ezáltal a teljes kapacitása előtt bekoppan az állomás.
Szóval ez nem nyert
Ennek akkor lehet értelme, ha van két carrier-ed, ahol az egyikről ki vannak tiltva a CS és Rel99 userek, de ebben az esetben is maximum 2db HS-SCH csatit tudsz konfolni, ez pedig könnyen kevés is lehet. De hangsúlyozom: nem találták volna ki a MIMO-t, ha tényleg 15 összefüggő üres kód kéne a működéséhez. Nincs az a 3gpp TSG, akik ehhez a nevüket adták volna.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
LordX
veterán
"Más gyártók BTS-ei a legrosszabb esetben is csak bővítőkártyát igényelnek ami valós időben integrálható" = CPU upgrade. A CPU is egy bővítőkártyán van
"A MIMO-hoz nem kell 15 kód" A szabvány nem ezt mondja. Hanem ezt:
3GPP TS 25.214 - 6A.2.3: bekezdés H-I-J-K jelű táblázatok írják le a MIMO módokat (4 táblázat, 4 üzemmód, 64QAM nélkül/-mal, DC nélkül/-vel). Mind a négy minden CQI-hoz tartozó sorában a "Number of HS-PDSCH" oszlopban 15 szerepel.
(TS 25.211 5.3.3.13: "A HS-PDSCH corresponds to one channelization code of fixed spreading factor SF=16".)
Tehát ha MIMO-t akarsz, 15 kód kell. A 10.0.0-s verziója a dokumentumoknak mondja ezt, tehát Rel10-ben is ez a helyzet.
-
dchard
veterán
"egyébként NSN-nél dolgozom, és nem, nem támogatja a BTS se - software upgrade kell, amihez jó valószínűséggel CPU upgrade is kell (ami drága)"
Talán ezért (is) cserél minden operátor más gyártóra kis hazánkban
Más gyártók BTS-ei a legrosszabb esetben is csak bővítőkártyát igényelnek ami valós időben integrálható, az újabb mostanában telepített BTS-ek pedig tudják alapból."a 64QAM még a legkisebb szívás az összes közül, de érdekes módon azt is még mindig csak BP környékén kapcsolta be a T és a Voda."
Meg kell cáfoljalak, ennél jóval kiterjedtebb a 21megás HSPA hálózat mindkét operátornál, bár kétségtelen, hogy az összes HSPA-képes bázisállomásnak csupán az 1/5-1/6-án van bekapcsolva a 21mega. De ettől még a támogatás nem probléma.
"A HSPA MIMO meg érdekes állat. A működéséhez 15 db SF16 kódra van szükség. Ha ugyanazon cellán indítasz egy Rel99-es DCH hívást (gyakorlatilag bármelyik 3G telefonon voice hívást kezdeményezel) na jó, kettőt, 1 hívás esetén még lehet szerencséd lesz, akkor máris csak 14db marad SF16 kód marad szabadon, tehát hiába támogat mindkét oldal MIMO-t, nem lehet használni. Ütemezgetésekkel jó jel-zaj viszony esetében ezt a jelenséget lehet kezelhető méretűre csökkenteni, de amíg léteznek legacy WCDMA eszközök, addig a MIMO messze nem fogja tudni azt, amit várni lehet tőle."
Nem tudom mit csinálsz az NSN-nél, de remélem nem rádiós vagy
, ugyanis több tévedés van benne:1. A MIMO-hoz nem kell 15 kód. Akárhány szabad kóddal működik (ajánlom figyelmedbe a 3gpp 25-ös csoportján belül a WCDMA fizikai rétegére vonatkozó specifikációkat és a modulációs táblázatokat), csak maximum lassabb lesz kevesebb kóddal, de ez összegészében igaz bármilyen 3G-s szolgáltatásra: minél több a szabad kód, annál gyorsabb az elérhető átvitel.
2. Nincs olyan hálózat, ahol elsődleges vivőn létezik 15 üres kód, ugyanis átlagosan 2-3 HSSCH csatornát szoktak használni, és ha még ehhez hozzáveszem a többi kötelező jelzéscsatornát, akkor már bőven nem férünk bele 1 kódba. Igazából az is nagyon ritka, hogy van 14 kód üresen, és ugye a bejövő CS hívásoknak is fenn kell tartanod helyet.
3. A MIMO-tól pont azt várja az iparág, hogy elsősorban a rossz vételi körülmények között biztosítson érzékelhető méretű javulást azzal, hogy sokkal inkább interferencia és fading tűrő a MIMO. Jó vételi körülmények között 64QAM-ot kell használni, cellahatáron és rossz vételi körülmények között MIMO-t.
Én inkább nem mondom meg hol dolgozom, de gondolom sejted, hogy eléggé a tűz közelében.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
LordX
veterán
Bázisállomásnál lehet (egyébként NSN-nél dolgozom, és nem, nem támogatja a BTS se - software upgrade kell, amihez jó valószínűséggel CPU upgrade is kell (ami drága), MIMO-hoz antenna upgrade (ami meg egy nagyságrenddel drágább, mint a CPU upgrade) - a 64QAM még a legkisebb szívás az összes közül, de érdekes módon azt is még mindig csak BP környékén kapcsolta be a T és a Voda..), de mobiltelefon, ami tudja a 64QAM-et az ritka mint a fehér varjú. Jelen piacon van kb. 5 db, olyan nagyágyúk, mint az iPhone 4S se tudja.
A HSPA MIMO meg érdekes állat. A működéséhez 15 db SF16 kódra van szükség. Ha ugyanazon cellán indítasz egy Rel99-es DCH hívást (gyakorlatilag bármelyik 3G telefonon voice hívást kezdeményezel) na jó, kettőt, 1 hívás esetén még lehet szerencséd lesz, akkor máris csak 14db marad SF16 kód marad szabadon, tehát hiába támogat mindkét oldal MIMO-t, nem lehet használni. Ütemezgetésekkel jó jel-zaj viszony esetében ezt a jelenséget lehet kezelhető méretűre csökkenteni, de amíg léteznek legacy WCDMA eszközök, addig a MIMO messze nem fogja tudni azt, amit várni lehet tőle.
[ Szerkesztve ]
-
dchard
veterán
"Eszköz utóbbihoz se lesz, mivel nem igazán támogatnak se a mostani telefonok, se a mostani bázisállomások se DC-HSPA-t, se 64QAM-et, se 2x2 MIMO-t."
Ez bizony tévedés. A jelenlegi bázisállomások nagy részén már be is van kapcsolva a 64QAM, és a nagyon régi első generációs alapsávi berendezéseket kivéve bármelyik tudja a DC-t is. MIMO-t pedig bárki bekapcsolhat, ha van pénze az antennarendszer átalakítására, csak hát ez elég sokba kerül (elsősorban munkadíjban), de ahogy a frekik fogynak, egyszer csak olcsóbb lesz MIMO-sítani, arról nem beszélve, hogy az LTE-nél már amúgy is mandatory a minimum 2x2 MIMO.
Én is azt gondolom, hogy inkább a HSPA+ evolúciónak kellene gyorsulnia. Egyébként 2011 Q3-Q4-re ígértek a nagyobb gyártók DC+64QAM+MIMO=84Mbit/s-ra képes adatkártyákat. Telefonban egyelőre a 21mega vagy a 28mega a maximum a 3G-s doménben.
Dchard
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
Erasmus
őstag
a technikai részleteket ilyen mélyen nem vágom, de a té a mostani lte-próbaüzemet 1800 mhz-n egy 10 mhz sávon nyomja, amit max. 60 mbps le- és 20 mbps-feltöltési sebességre lőttek be. (az ericssonnal folytatott teszt során tavaly 20 mhz-en 100 mbps fölé mentek letöltésben.) nálunk is van egy modem, a gyakorlatban ez így néz ki:
[ Szerkesztve ]
-
LordX
veterán
10 MHz-es sávon az LTE maximuma 36696 kbps / MIMO stream - jellemzően 2x2 esetében 73,3 Mbps.
A DC-HSPA (azaz 2x5MHz sávval) 64QAM-el, 2x2 MIMO-val 84 Mbps.
Tehát nemhogy 'alig jobb', hanem rosszabb. Eszköz utóbbihoz se lesz, mivel nem igazán támogatnak se a mostani telefonok, se a mostani bázisállomások se DC-HSPA-t, se 64QAM-et, se 2x2 MIMO-t. De legalább visszafelé kompatibilis, fel tud rá csatlakozni a 'hagyományos' HSPA user equipment is.
A Telenor nem csinált hülyeséget, amikor elindította a Hipernetet.
Az LTE akkor kezd jobb lenni, amikor több, mint 10 MHz elérhető egy helyen, de az egyébként lehet sok kis darabban is (1,4 MHz itt, 2 MHz ott..)
[ Szerkesztve ]
-
dchard
veterán
Konkrétan semmire nem elég.
Jelenleg mindhárom hazai operátor használ már két vivőt (2x5 azaz 10MHZ-et) HSPA+ szolgáltatásra, méghozzá elég kiterjedten, és lassan eljutunk oda, hogy a 3. vivőt is be kell majd kapcsolni.
De maradjunk a 10MHz-nél. Ekkora sávban azonos technológiai feltételek (moduláció, kódolás, antenna-rendszer) az LTE a legjobb esetben is csak 1,1-1,2-szer "gyorsabb", vagy mondjuk inkább így: hatékonyabb a jelenleg is működő HSPA+ technológiánál.
Ennek két oka van:
1. Nem találta fel senki a spanyol viaszt, Ahhoz, hogy nagyobb sebességet érjünk el vagy több sávszélesség kell (nincs, esetünkben a 10MHz ugye adott), vagy több adatot kell átvinni időegység alatt (magasabb moduláció, ami gyakorlatilag csak line-of-site működik). Az igaz, hogy az OFDMA nagyobb sávszélességeken hatékonyabban működik mint a WCDMA, de csodák nincsenek.
2. A HSPA+ hálózathoz nagy penetrációban vannak eszközök, amivel az ember használni is tudja a szolgáltatást és nem csak vakítják a létezésével. Arról nem beszélve, hogy a legtöbb magyar nagyvárosban már most is van működő kereskedelmi HSPA+ szolgáltatás.
Az LTE-nek maximum annyiban van előny, hogy a szabvány alapból megköveteli a 2X2MIMO-t a szolgáltatóktól és az eszköz gyártóktól is, illetve számos a rádiós erőforrásokkal spóroló kiegészítést is kötelezően tartalmaz, ami a HSPA hálózatoknál lassan szivárog le a tömegekhez, mivel ehhez le kell cserélni a modemet újabb típusra.
Például erősen kívánatos lenne, ha a csak HSDPA-t ismerő készülékek gyorsan eltűnnének a hálózatokból, mivel ezek pazarolják a rádiós erőforrásokat. Aki teheti vásároljon legalább HSUPA-képes eszközt.
Dchard
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
"Magyarországon és a környező országokban a 800 MHz-es és a 2,6 GHz-es sávot szemelték ki a szolgáltatók a negyedik generációs, például LTE-technológián alapuló mobilhálózatok számára."
A szolgáltatók olyan jól kiszemelték ezt, hogy jelenleg senki nem szolgáltat ebben a két sávban, viszont a T-Mobile kereskedelmi LTE hálózata a GSM 1800-as sávban üzemel.
A 800-as sáv az analóg földfelszín lelövése miatt késik, ezt a kormány eltolta.
A 2600-ra szintén nem írtak még ki tendert és távlati terv sincs róla, hogy mikor fognak.
900MHz-en senkinek sincs elég sávszélessége.Úgyhogy az elkövetkező bő évben halandók számára is elérhető LTE maximum a GSM1800-as sávban lesz majd elérhető.
Ez azért probléma, mert ott is 15MHz-es sávval rendelkeznek az operátorok, és ebből legalább 5MHz-et megeszik a GSM (inkább többet), 10MHz-ben meg parasztvakítás az LTE, hiszen alig valamivel jobb a bit/Hz aránya ekkora sávban, mint a HSPA+-nak: sem sebességben sem késleltetésben nem veri el a jelenlegi technológiát, viszont sokkal több pénzbe kerül annál, és eszközök sem nagyon vannak hozzá.
Gondoltam kicsit árnyalom a képet, mielőtt mindenkinek feláll az LTE-re
Dchard
[ Módosította: Erasmus ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
Örülök, hogy rád akadtam. 
Más gyártók BTS-ei a legrosszabb esetben is csak bővítőkártyát igényelnek ami valós időben integrálható, az újabb mostanában telepített BTS-ek pedig tudják alapból.
Új hozzászólás Aktív témák
it A most aláírt egyezmény szabályozza a negyedik generációs mobilfrekvenciák határövezeti használatát.
- Soundbar, soundplate, hangprojektor
- Mibe tegyem a megtakarításaimat?
- eBay-es kütyük kis pénzért
- Hardcore café
- PR-Telecom
- Hobby rádiós topik
- Xbox Series X|S
- Milyen Android TV boxot vegyek?
- Google Pixel topik
- Felháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasni
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest