I'm not sure what to make of this timing difference. I'm using sysmoBTS
hw to test different osmoPCU versions (including ssharan/egprs) and I
can see pacch timeouts on all of those I've tried. For some phones it
really breaks connectivity, others seems to be able to ignore it
somehow. I do not see a pattern yet.
Do you have some test setup where you try it and see if it's the same
for you?
On 02/26/2016 04:13 PM, Saurabh Sharan wrote:
Hello Max,
Though I have not analyzed the missing UL poll response, few of my
observations from the pcap file attached is mentioned below
1. There seems to be difference in FN UL versus DL being processed at
any given time by the order of approx. 10 FNs, example given below
1. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
2. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972
3. From above example difference in time is 48milliseconds or
approx.. 10FN duration
2. For processing DL timeslots 2 to 6 at any given DL FN time taken
seems to be approx. 3milliseconds, example given below
4. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
5. Packet 7178, FN 1137361 in DL @ 15:33:22.514310379 for TS 6
Please let me know if these are known behavior in your integration
environment ?
These time variations may have an impact on the poll response behavior
from MS as well.
Regards
Saurabh
-----Original Message-----
From: Max [mailto:msuraev@sysmocom.de]
Sent: Thursday, February 25, 2016 3:58 PM
To: osmocom-net-gprs(a)lists.osmocom.org; Saurabh Sharan
<Saurabh.Sharan(a)radisys.com>
Subject: PCU scheduling and PACCH timeout question
Hello.
I'm trying to debug issue with current OsmoPCU master when some
basebands ignore polling requests.
The debug output from RLCMAC layer and corresponding .pcap files are
attached.
The issue appears somewhere after line 112 in debug.log The
corresponding packet in pcu.pcapng is 6866
After receiving PACKET_CONTROL_ACK from phone we're trying to schedule
polling at FN 1137123 (see packet 6869 in pcap) and than at FN 1137127
(packet 6874) which subsequently fails.
This seems suspiciously close but I have not found in the spec yet if
this is legitimate thing to do.
There are several other occurrences like that in both log and pcap.
Have you experienced something like this? Do you have an idea why only
some basebands are affected while others work fine?
--
Max Suraev <msuraev(a)sysmocom.de <mailto:msuraev@sysmocom.de>>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
--
Max Suraev <msuraev(a)sysmocom.de>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte