Cellular Network Infrastructure » Radio Access Network » OsmoPCU

Attached is the log with extra debug info obtained from osmopcu with acer phone trying to connect.

Bigger and cleaner log for reference.

Attaching latest logs.

Tested with dynamic TS - same results as with static config.

Gerrit 2859, 2654, 2673 are merged. This does not fix the issue but should make debugging it easier.

I am able to reproduce this issue reliably with two MS's in my possession, a Lenovo A319 and a BLU Dash 3.5(Mediatek MT6572M). I see similar behavior between my SDR setup osmo-pcu(0.5.0.9.3df1), osmo-bts-trx(0.8.1.20.0257), and osmo-trx-uhd(4.9.2; Boost_105500; UHD_003.009.005) and an embedded setup based on a Nuran Litecell 1.5 osmo-pcu(0.2.0.936-85cf), and osmo-bts-lc15(0.4.0.566-eb5b7). lynxis please let me know if there is any prototype testing or debug I can do to aid your development.

I was also able to test with a newer mediatek phone, and the issue still persisted. Log attached.

Phone: Gionee P5-Mini
Released: April 2016
Chipset: Mediatek MT6580M

I appear to be seeing this with Motorola KRZR K3

https://osmocom.org/issues/3472

I wonder if some of these issues could instead be related to the broken Uplink ACK/NACK bitmaps which we discovered recently. We'll push a workaround (not a real fix yet, unfortunately) and I would appreciate if people with "broken" phones retest.

On phones. I have two K3s, so can and will test anything, although that is not the same as having one on the desk to probe.. I could leave one at sysmocom sometime.

There are quite a number of models of phones mentioned in this ticket. As zecke originally says, I've noticed the iPhone5c very stable on this, always sends (doesn't exhibit #2455), always receives. I have a Huawei U8350 about which I can say the same.

Not so with Asus Zenfone2 and HTC desire 628 - Both give very frustrating UX, with both phone and network initiated data transfer when idle unstable and difficult to reproduce. They keep resetting the pdp-context too.

Yesterday I briefly searched internetz for a database of what phones have what basebands and other relevant things but other than some sparse info on sites like XDA-developers I did not find such a thing. I wonder does such a thing exist? If we knew, then laforge maybe we can find another phone with same/similar characteristics. There were really a LOT of Motorola RAZR types in the series. The KRZR K3 is hard to find for some reason, but the K1 is plentiful. I wonder how different they are under the skin?

I seem to remember a mention someplace sometime of making our own database of GPRS status with phone models..

On broken ACK/NACK bitmaps and patches ipse I searched all tickets for "bitmaps", I only found #1624. Can you make a ticket about what you discovered + Please ping me when the workaround is there to test.

ipse I would be happy to test when code is available. Please update this ticket with the desired tests and workaround branch or direct message me and I can run the tests you need and upload results here.

laforge and keith we have a ton of low-end phones that exhibit this problem here. I can try and send you some if it would be helpful to add to the Sysmocom testbench. The shipping cost from the US would probably be significantly greater than the new market value of the phones themselves though. If you pick up any cheap handset with a Mediatek chipset from our experiences so far it will likely exhibit this problem. https://www.gsmarena.com/ doesn't have a searchable database by chipset, but does have chipset information available for most recently released handsets and searchable by phone model. I just tried to look up the K3 (from 2007) and it unfortunately doesn't seem to have any chipset info.

I was thinking about the title of this ticket..

Not saying that this is not an issue, but a couple of things to occurred to me:

1) I was experiencing what looks like this problem (exactly as described in comment https://osmocom.org/issues/1524#note-2) when I only have ONE PDCH configured, so how could the problem be the wrong TS? [ EDIT: I'm not 100% sure that I was seeing "Downlink ACK was received" ]

2) I discovered yesterday that since http://git.osmocom.org/osmo-pcu/commit/?id=9bbe1600cc02e1b538380393edb1dcdabe9247a2 osmo-pcu is sending an invalid Timing Advance of 220 when we page to setup a TBF DL. This is because we don't know TA if the previous TBF UL is gone. The correct procedure to ascertain TA in this case needs to be implemented. This totally makes sense and explains why I always saw bursts on the spectrum - the phone responding to the paging, but the BTS/PCU not receiving because of the erroneous TA.

I would suppose then that some phones see the Invalid TA of 220 and react with:
"oh that's invalid, I'm going to use 0" and given that we are probably testing within 550m it works.

and others say "oh that's invalid I'm going to use 63" and as we are not 35km away it doesn't work. :-/

BTW, I read this document which I found highly useful. It's rather a critical analysis of GPRS design rather that a description of how it works, but one can glean a lot of info from reading it, much faster than reading specs. (The intro is in German + English, the rest of the doc is english, so don't look at the first page and shy away, non german speakers)
https://publik.tuwien.ac.at/files/PubDat_112092.pdf

[ 2nd EDIT: I think this comment should be on #1526 and I have not actually seen anything I can be sure relates to this ticket. ]

Sorry to be so messy with my comments.. I'm overloading my brain a bit with a personal crash-course on the PCU. :-/
I appear to be seeing something like this now if I use
egprs only
in the pcu config.

I purchased a KRZR 3 for the sysmocom lab. Not sure when somebody will be able to try to reproduce, but at least we should be able to do now.

moving PCU related tickets to pespin

A lot of stuff has happened in osmo-pcu since the comments 3-4 years ago. IMHO it's nowadays a lot easier to debug stuff with the current FSMs.

laforge is there still a KRZR 3 in the sysmocom office still today? May it be worth posting it to me to give it a try? or better someone at the office give it a test with osmocom master and see if there's still visible issues and report a pcap with gsmtap + gsmtap_log to me.

assigning to roh to provide the related test / captures / logs.