26 Feb
2016
26 Feb
'16
9:40 p.m.
On 26 Feb 2016, at 16:13, Saurabh Sharan
<Saurabh.Sharan(a)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