26 Feb
2016
26 Feb
'16
4:13 p.m.
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
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972
c. 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
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
b. 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@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
26 Feb
26 Feb
6:07 p.m.
New subject: PCU scheduling and PACCH timeout question
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
9:23 p.m.
New subject: PCU scheduling and PACCH timeout question
Hello Max,
Please find below chart that indicate time skew is happening in the setup.
I have also attached the excel sheet used for this analysis here for reference.
TS4 in downlink is considered for drawing the plot. Please note that block duration value
of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of
4,4,5,4,4,5,..and so on.
4FN duration is 18.4ms and 5 FN is 23 ms approx.
But the spikes in the system as high as 26.8ms may result in incorrect air interface
behavior from L1.
[cid:image002.png@01D17101.8DA5BBD0]
Regards
Saurabh
From: Max [mailto:msuraev@sysmocom.de]
Sent: Friday, February 26, 2016 10:37 PM
To: Saurabh Sharan <Saurabh.Sharan(a)radisys.com>om>;
osmocom-net-gprs(a)lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question
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
a. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393
b. Packet 7190, FN 1137361 in UL @ 15:33:22.559427972
c. 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
d. Packet 7174 , FN 1137361 in DL @ 15:33:22.511809393 for TS 2
e. 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@lists.osmocom.org<mailto:osmocom-net-gprs@lists.osmocom.org>;
Saurabh Sharan
<Saurabh.Sharan@radisys.com><mailto:Saurabh.Sharan@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@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@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
29 Feb
29 Feb
6:52 p.m.
New subject: PCU scheduling and PACCH timeout question
On 26 Feb 2016, at 21:23, Saurabh Sharan
<Saurabh.Sharan(a)radisys.com> wrote:
Hello Max,
Dear Saurabh,
Please find below chart that indicate time skew is
happening in the setup.
I have also attached the excel sheet used for this analysis here for reference.
TS4 in downlink is considered for drawing the plot. Please note that block duration value
of 18 and 23 milliseconds are acceptable as transmission FNs increment by pattern of
4,4,5,4,4,5,..and so on.
4FN duration is 18.4ms and 5 FN is 23 ms approx.
But the spikes in the system as high as 26.8ms may result in incorrect air interface
behavior from L1.
how did you extract the values? Did you create a lua script for wireshark/tshark? It would
be interesting to automate this.
kind regards
holger
1 Mar
1 Mar
8:05 a.m.
New subject: PCU scheduling and PACCH timeout question
Hello Holger,
The extraction was done manually from wireshark capture file. I have not created any
script for this.
Steps were
* Set time display format in wireshark capture for microseconds and from beginning
of capture
* Filter the log for TS 4 (control TS was chosen) and direction downlink
((gsmtap.uplink == 0) && (gsmtap.ts == 4))
* Keep column display for GSM Frame Number in the wireshark capture
* After this Print "output to file" utility in wireshark for "as
displayed" converts the displayed capture into text
* Copy entire text and delimit with whitespace in an excel sheet
* Add formula for time difference and frame number difference between previous to
next row (for time difference multiply by 1000 to get milliseconds)
* These new rows will serve as further elements for plot and analysis
Regards
Saurabh
-----Original Message-----
From: Holger Freyther [mailto:holger@freyther.de]
Sent: Monday, February 29, 2016 11:22 PM
To: Saurabh Sharan <Saurabh.Sharan(a)radisys.com
Cc: Max <msuraev(a)sysmocom.de>de>; osmocom-net-gprs(a)lists.osmocom.org
Subject: Re: PCU scheduling and PACCH timeout question
On 26 Feb 2016, at 21:23, Saurabh Sharan
<Saurabh.Sharan@radisys.com<mailto:Saurabh.Sharan@radisys.com>> wrote:
Hello Max,
Dear Saurabh,
Please find below chart that indicate time skew is
happening in the setup.
I have also attached the excel sheet used for this
analysis here for reference.
TS4 in downlink is considered for drawing the plot.
Please note that block duration value of 18 and 23 milliseconds are acceptable as
transmission FNs increment by pattern of 4,4,5,4,4,5,..and so on.
4FN duration is 18.4ms and 5 FN is 23 ms approx.
But the spikes in the system as high as 26.8ms may
result in incorrect air interface behavior from L1.
how did you extract the values? Did you create a lua script for wireshark/tshark? It would
be interesting to automate this.
kind regards
holger
26 Feb
26 Feb
9:40 p.m.
New subject: PCU scheduling and PACCH timeout question
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
2983
days inactive
2987
days old
osmocom-net-gprs@lists.osmocom.org
5 comments
3 participants
participants (3)
-
Holger Freyther -
Max -
Saurabh Sharan