This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Keith keith at rhizomatica.orgOn 16/01/2019 18:55, Harald Welte wrote: > hi Keith, > > it is my understanding that the TA value of osmo-pcu is working as expected, > as the timing offset is established durign TBF establishment. What osmo-pcu > is missing is the PTCCH signalling to continuously adjust the timing advance > as the timing offset evolves during an onging TBF. Right. I'm aware of the missing part. What I noticed last summer with a phone on my desk a few metres from the BTS, that is to say, in Timing Advance "zone" 0, is this: If I change this line: http://git.osmocom.org/osmo-pcu/tree/src/tbf_dl.cpp#n130 replacing GSM48_TA_INVALID (defined as 220 in libosmocore) with 0 then I get much better performance, as in "it works", and with GSM48_TA_INVALID of 220 "it doesn't work" :) What seems to be not working as expected is the logic of the invalid TA, some phones just don't seem to like this, either that, OR the phones respond correctly to the invalid TA, and we are not dealing right with the response. Sorry.. I actually haven't looked at all the traces and work I did last summer, and memory is vague on the specifics. I actually want to do the experiments again, but with a variable INVALID_TA > > So for a subscriber at a [relatively] fixed distance from the BTS (like the population > centre you're describing), it *should* be working. > It isn't working. confirmed multiple times. It varies phone by phone, but basically, it goes like this: start: establish pdp context, send data. recv data.. all good until we have no data for a few seconds... TBF times out. Next, phone or network has data. network pages, phone does not respond. or phone sends RACH bursts, network does not respond. wait.... Eventually, this times out, pdp context is torn down. wait.... goto start. Which all makes for a "working" but rather frustrating instant messaging experience. > Please note that Sylvain has just very recently designed an open source > "timing advance generator" under sysmocom contract, ant using that device > (based on the PLUTO-SDR) plus some coaxial wiring/attenuators, it should be > rather easy to simulate both static as well as changing timing advance. Yep, and this is great! I think it's going to help a lot to debug and get this sorted out. > > The project is called 'osmo-rfds' (for RF Delay Simulator), see http://git.osmocom.org/osmo-rfds/ > > If OsmoPCU was just always operating at a static timing advance, I would > agree that a VTY command would be a possible interim hack. But AFAIK, the > PCU is not actually that limited ;) OK, so i didn't mean to implement a static timing advance, just to try a different "Invalid" TA to start with instead of 220. > Please help to clarify, thanks. hope that helps. Anyway, for sure, I can just implement the vty command for my tests, (and push to a private branch). Not something we really need in master. But if it were there.. people might be more inclined to test it out.. and that might help at least to debug/clarify this issue? (which I think is very much confused by the "works for me" element, like for example if you happen to use say, an iPhone 5c, which is one I have seen to work fine. :) k/