PCU scheduling and PACCH timeout question
msuraev at sysmocom.de
Fri Feb 26 17:07:07 UTC 2016
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
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.
> -----Original Message-----
> From: Max [mailto:msuraev at sysmocom.de]
> Sent: Thursday, February 25, 2016 3:58 PM
> To: osmocom-net-gprs at lists.osmocom.org; Saurabh Sharan
> <Saurabh.Sharan at radisys.com>
> Subject: PCU scheduling and PACCH timeout question
> 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
> 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 at sysmocom.de <mailto:msuraev at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osmocom-net-gprs