Project

General

Profile

Feature #1672

add gprs decoding utility

Added by msuraev almost 2 years ago. Updated 15 days ago.

Status:
Feedback
Priority:
Low
Assignee:
Category:
OsmocomBB Layer 1 (Coding)
Target version:
-
Start date:
03/24/2016
Due date:
% Done:

70%

Resolution:
Spec Reference:

Description

Add tool (osmocom-bb based) which can record and decode gprs messages.
Useful starting point: https://srlabs.de/gprs/


Related issues

Related to libosmocore - Bug #1629: add convolution generators to libosmocore Closed 03/02/2016
Related to OsmoSGSN - Bug #1794: support random IV for GEA (via XID) Stalled 08/09/2016
Blocked by libosmocore - Bug #1960: GSM 05.03 conv_test fails Closed 03/01/2017

History

#1 Updated by msuraev almost 2 years ago

  • Project changed from OpenBSC to OsmocomBB

#2 Updated by msuraev almost 2 years ago

  • Related to Bug #1629: add convolution generators to libosmocore added

#3 Updated by laforge almost 2 years ago

please keep ticket status updated. This issue cannot be 'new' as I know you already worked on it extensively.

#4 Updated by msuraev almost 2 years ago

  • Status changed from New to In Progress

#5 Updated by msuraev almost 2 years ago

The initial version is available in max/gprs_debug branch of osmocom-bb. It's roughly equivalent to original srlabs tool. Next steps: add MCS1-9 support - first to libosmocore, than to gprs_debug.

#6 Updated by msuraev over 1 year ago

  • % Done changed from 0 to 20

#7 Updated by laforge over 1 year ago

  • Priority changed from High to Normal

#8 Updated by msuraev about 1 year ago

  • Status changed from In Progress to Stalled

#9 Updated by msuraev about 1 year ago

Note: MCS1-9 is supported by libosmocore now.

#10 Updated by fixeria 12 months ago

  • Blocked by Bug #1960: GSM 05.03 conv_test fails added

#11 Updated by laforge 11 months ago

  • Priority changed from Normal to Low

#12 Updated by msuraev 30 days ago

To avoid bitrot in branch, actual utility was submitted for inclusion in master in gerrit 5992. To use hw for capturing, burst_ind branch is still required so the max/gprs_debug with necessary fixes on top of it is left intact for now.

#13 Updated by msuraev 30 days ago

  • Related to Bug #1794: support random IV for GEA (via XID) added

#14 Updated by fixeria 15 days ago

  • Category set to OsmocomBB Layer 1 (Coding)
  • Status changed from Stalled to Feedback
  • % Done changed from 20 to 70

I would like to clarify a few points about MCS (i.e. EDGE) decoding.
Despite the libosmocoding do support this now, it's impossible at the
moment. The problem is that Calypso-based phones aren't usable for
EDGE burst capture, because they don't support 8-PSK modulation.

I think, it would be better to use SDR here, since there are no
signal processing limitations. My idea is to extend the GR-GSM
project with 8-PSK modulation support, and it was already
discussed with Piotr.

Regarding to the current state of the gprsdecode utility,
the code was updated to use libosmocoding and ready to
be submitted in the master.

#15 Updated by laforge 15 days ago

On Tue, Feb 06, 2018 at 08:16:35AM +0000, fixeria [REDMINE] wrote:

I would like to clarify a few points about MCS (i.e. EDGE) decoding.
Despite the libosmocoding do support this now, it's impossible at the
moment. The problem is that Calypso-based phones aren't usable for
EDGE burst capture, because they don't support 8-PSK modulation.

this is incorrect. EGPRS != 8PSK. The lower 4 (or 5?) MCS are using
GMSK and can be supported from osmocombb/calypso/gprsdecode

There are even quite a number of (old, cheap) phones which support
EDGE/EGPRS, but do not support 8PSK but only GMSK modulation. This
relates to the fact that the switch from GMSK->8PSK requires different
(more linear) power amplifiers, which is a hardware change. The
GPRS -> EGPRS change was a pure software change.

I think, it would be better to use SDR here, since there are no
signal processing limitations. My idea is to extend the GR-GSM
project with 8-PSK modulation support, and it was already
discussed with Piotr.

I'm not sure it's "Better". Always depends on your use case.

Using the calypso based phones + gprsdecode is very quick to set-up,
doesn't require lots of CPU resources and simply works. Not to ignore
the difference in price of a factor or 10-30.

Sure, for tracing 8PSK you have to go to a SDR. But for most of the OsmoPCU
related debugging we'd want to do in Osmocom, I would argue it's not needed.
One can simply enable EGPRS but disable 8PSK and then all the tests related
to the EGPRS protocol can be performed. At least that's my current opinion.

#16 Updated by fixeria 15 days ago

this is incorrect. EGPRS != 8PSK. The lower 4 (or 5?) MCS are using
GMSK and can be supported from osmocombb/calypso/gprsdecode

Thanks for this clarification, I didn't know that. This way gprsdecode
utility may be extended in the future. The main question for me now
is do GMSK-modulated and MCS-encoded bursts use both the same burst
length and structure as GSM bursts?

Using the calypso based phones + gprsdecode is very quick to set-up,
doesn't require lots of CPU resources and simply works. Not to ignore
the difference in price of a factor or 10-30.

Agree with you here. From the other side, one could use extra-cheap
and available RTL-SDR. The provided bandwidth and frequency range is
more than enough for the mentioned purposes.

#17 Updated by laforge 15 days ago

On Tue, Feb 06, 2018 at 12:16:30PM +0000, fixeria [REDMINE] wrote:

Issue #1672 has been updated by fixeria.

this is incorrect. EGPRS != 8PSK. The lower 4 (or 5?) MCS are using
GMSK and can be supported from osmocombb/calypso/gprsdecode

Thanks for this clarification, I didn't know that. This way gprsdecode
utility may be extended in the future. The main question for me now
is do GMSK-modulated and MCS-encoded bursts use both the same burst
length and structure as GSM bursts?

yes, it's just different convolutional code / puncturing scheme. Feel free
to look at the first couple of MCS, those with lower number.

Using the calypso based phones + gprsdecode is very quick to set-up,
doesn't require lots of CPU resources and simply works. Not to ignore
the difference in price of a factor or 10-30.

Agree with you here. From the other side, one could use extra-cheap
and available RTL-SDR. The provided bandwidth and frequency range is
more than enough for the mentioned purposes.

Indeed.

Also available in: Atom PDF