30 May
2016
30 May
'16
11:58 a.m.
Date: Fri, 27 May 2016 18:02:28 +0200
From: Pierre Baudry <pierre.baudry(a)diateam.net>
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses
NuRAN hardware with osmo-bts-sysmo
The latest "good" revision I am aware of is
commit
d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
This is a useful information for us that the above mentioned commit works for GPRS.
Can somebody confirm or reproduce this attitude ?
The PCU log that we have during failure matches with the one you have reported.
We have tried a workaround for this GPRS call failure by forcing two-phase-access in
osmo-pcu.cfg.
Based on our analysis done till now it seems One phase access of GPRS is broken.
I will try to provide more logs and a pcap capture as
soon as I get
hands back on the hardware.
It will be quite useful to narrow down the issue, so please share the relevant logs
collected
Regards
Saurabh
16 Jun
16 Jun
3:03 a.m.
New subject: Regression in osmo-pcu with UHD trx ?
On Mon, May 30, 2016 at 2:58 AM, Saurabh Sharan
<Saurabh.Sharan(a)radisys.com> wrote:
I can confirm the same behaviour on B200 using master branches of
osmo-pcu, osmo-bts-trx, and osmo-trx.
Confirm matching PCU log and that enabling two-phase-access works
around the issue.
-TT
Date: Fri, 27
May 2016 18:02:28 +0200
From: Pierre Baudry <pierre.baudry(a)diateam.net>
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses
NuRAN hardware with osmo-bts-sysmo > The latest "good" revision I am aware of
is commit
> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
Confirm.
Can somebody
confirm or reproduce this attitude ?
The PCU log that we have during failure matches with the one you have reported.
We have tried a workaround for this GPRS call failure by forcing two-phase-access in
osmo-pcu.cfg.
Based on our analysis done till now it seems One phase access of GPRS is broken. 
1:43 p.m.
New subject: Regression in osmo-pcu with UHD trx ?
On Wed, Jun 15, 2016 at 06:03:29PM -0700, Tom Tsou wrote:
On Mon, May 30, 2016 at 2:58 AM, Saurabh Sharan
<Saurabh.Sharan(a)radisys.com> wrote:
I can confirm the same behaviour on B200 using master branches of
osmo-pcu, osmo-bts-trx, and osmo-trx.
Maybe related: I have recently found osmo-pcu master to not work for ip.access
nanobts (and probably for all BTS models) and traced it to commit
f1a7b8f tbf: Add state WAIT_ASSIGN
See https://gerrit.osmocom.org/218
We still have to come to a conclusion on whether we want to merge the revert.
If anyone is aware of this, any details would be appreciated.
Thanks!
~Neels
Date:
Fri, 27 May 2016 18:02:28 +0200
From: Pierre Baudry <pierre.baudry(a)diateam.net>
I noticed that since several weeks that osmo-pcu did not work as good as
previously.
Yes we have also seen similar failures for GPRS calls in the osmo-pcu. Our setup uses
NuRAN hardware with osmo-bts-sysmo > The latest "good" revision I am
aware of is commit
> d87e1d6ab747423d3668c74d16201a5d967accf0 (2015/12/14)
Confirm.
7:44 p.m.
New subject: Regression in osmo-pcu with UHD trx ?
On Thu, Jun 16, 2016 at 4:43 AM, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote:
Maybe related: I have recently found osmo-pcu master
to not work for ip.access
nanobts (and probably for all BTS models) and traced it to commit
f1a7b8f tbf: Add state WAIT_ASSIGN
See https://gerrit.osmocom.org/218
We still have to come to a conclusion on whether we want to merge the revert.
If anyone is aware of this, any details would be appreciated.
Reverting "f1a7b8f tbf: Add state WAIT_ASSIGN" restores single phase
GPRS access on osmo-bts-trx / osmo-trx.
End-to-end functionality appears fine, but I cannot comment on if or
how the change affects protocol or performance on a more detailed
level.
-TT
2877
days inactive
2894
days old
3 comments
3 participants
participants (3)
-
Neels Hofmeyr -
Saurabh Sharan -
Tom Tsou