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/osmocom-net-gprs@lists.osmocom.org/.
Holger Freyther holger at freyther.de> On 26 Feb 2016, at 16:13, Saurabh Sharan <Saurabh.Sharan at radisys.com> wrote: > > Hello Max, Dear Saurabh, > Though I have not analyzed the missing UL poll response, few of my observations from the pcap file attached is mentioned below > • 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 > • Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 > • Packet 7190, FN 1137361 in UL @ 15:33:22.559427972 > • From above example difference in time is 48milliseconds or approx.. 10FN duration > • For processing DL timeslots 2 to 6 at any given DL FN time taken seems to be approx. 3milliseconds, example given below > • Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2 > • 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. In general the timing is to be expected. Our processing chain is that the DSP will request a frame by sending a "RTS.IND" and it will start to queue some frames before the next one. So we need to generate the frame some time before the first burst is being sent. While for received data frames we get the decoded frame after the last burst has been processed. Do you have an independent receiver that can receive GSMK/8PSK and send the output to GSMTAP. It would be very helpful to see if we actually sent the data at the right frame number on the right timeslot. What is your setup to verify such a setup? kind regards and have a nice weekend holger