Door Anoniem:
Nu heeft mijn mobiele netwerk kennis ook best wat lacunes, maar zo te zien zit er hier niemand echt goed in.
In een analoge peiling heb je typisch peilstations die alleen een richting kunnen vaststellen (geen afstand) . Dus heb je er minimaal twee nodig .
In GSM netwerken wordt een vrij precieze klok gebruikt om de bitten in het bedoelde timeslot te laten uitkomen.
Ook op de vrij korte afstand van tientallen kilometers is de lichtsnelheid al relevant .
De term is 'timing advance'
https://en.wikipedia.org/wiki/Timing_advanceDan is er het feit dat een mast meestal sector antennes heeft , en daaruit een (ruwe) richting (120 graden) haalt .
Een enkele mast levert dus (al) een cirkel-segment waar een device moet zitten.
Als je beweegt van mast naar mast is - in combinatie met een (wegen)kaart je oorspronkelijke positie al een stukje zekerder te herleiden omdat je bron het deel van het cirkel-segment is vanwaar uit je overstapt naar _die_ volgende mast .
En ongeveer altijd via een route over een weg.
Waar ik geen inside kennis van heb - hoe (goed) de operators dat soort ruwe data (mast, antenne, timing advance) dan naar een een locatie met marge vertalen.
In alle sectoren IT waar ik _wel_ weet hoe het werkt is het een feit dat (meta)data die niet technisch nodig is voor de dienst, of voor de billing gewoon vervuilt . En des te meer als het in eerste instantie ingevuld moet worden door monteurs/field engineers voor wie het een "nutteloos" is , en de backoffice niet kan controleren of het ook goed gedaan is.
- denk aan interface descriptions, gebruikte patch poorten, vezelnummers, rack posities etc.
Je moet als organisatie heel hard werken om de werkelijkheid en de database in sync te houden.
Voor zo'n mobiele locatie moet de mast positie , (en de mapping van de juiste mast naar de juiste locatie), en de kijkrichting van de antennes goed ingemeten zijn.
Hoeveel marge een kloksignaal mag hebben voordat het een merkbare storing geeft - versus de waarde waarmee gerekend wordt voor TA - geen idee of de marge voordat het een storing geeft niet veel groter is .
Wat ik ook niet goed weet is of het netwerk een mobiel device (al) op meerdere nabije masten ziet - wellicht ter voorbereiding van een snelle handover, of dat het device zelf aan de hand van de signaalkwaliteit tijdens beweging besluit over te stappen naar een volgende mast.
Met weinig zoekwerk vond ik dat :
https://www.researchgate.net/publication/256736858_A_Survey_of_Cellular_Positioning_Techniques_in_GSM_NetworksHet is ietwat oud (2012), en ik haal er niet meteen uit wat gedaan WORDT , versus wat "in principe mogelijk is".
Anyway - ik schreef al dat parameter tweaks in L1/L2 mobiel gedrag in de baseband zullen zitten, en die is nooit open. Of het OS dit soort parameters kan tweaken (bij initialisatie of call setup) - geen idee.
Aangezien er geen enkele "normale" reden voor is - kans dat het niet in de API zit of heel erg obscuur is en amper gedocumenteerd.
(parameters als het kiezen van een andere operator om mee te roamen hebben wel een 'normale' reden en zijn dus stuurbaar door het OS.)[/quote]
Daar haal je een paar interessante punten aan. Met 3 sector antennes per mast is een basale triangulatie reeds mogelijk. Ik neem aan dat de data die gelogt wordt en voor het switchen van netwerken gebruikt wordt bestaat uit een identifier + een signaalsterkte. Met 3 directionele antennes op één punt valt de afstand van de mast en de richting van het signaal goed af te leiden (bah, het begint steeds minder mogelijk te lijken). ik denk trouwens ook dat die data van iedereen, inclusief telefoons die niet aangesloten zijn, gewoon gelogt en gebruikt wordt en dat er geen selectie noodzakelijk is. De data wordt immers doorverkocht dus is nuttig en waardevol terwijl de opslagcapaciteit die nodig zou zijn wel meevalt. Bij een extreme bevolkingsdichtheid van 6000 mensen per km2 zoals in Amsterdam (gemiddeld is het iets meer dan 500 in Nederland), en bij een afstand van 2 km tussen zendmasten is het oppervlakte van het bereik dus 12.56km2 en het aantal zichtbare signalen als iedereen een telefoontje heeft 75360 signalen maal 3 antennes = 226080 signalen per mast om te loggen. Als dB is uitgedrukt in 2 decimalen, en de identifier uitsluitend de IMEI(15 digits) is en er gelogt wordt in ascii (7 bit per karakters), dan gaat het dus om zo'n 20 karaktersx7bit = 140 bits per log x 3 antennes x 226080 telefoontjes = 94953600 bit, of zo'n 11.87MB per log van iedereen. Als dat iedere 10 seconden gelogt wordt dan is dat iets meer dan 4GB per uur. Als er uitsluitend wordt gelogt zodra de signaalsterkte van een telefoon significant verandert (en de telefoon dus in beweging is), dan kan hier flink op worden bezuinigd. En dit is dus het meest extreme geval. Technisch prima allemaal te loggen dus. Zelfs als een telefoon niet is aangemeld. Ik heb het pdfje nog even niet gelezen nu. Daar moet ik even de tijd voor nemen, maar bedankt.