16 Jan
2019
16 Jan
'19
7:36 p.m.
On 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/