MS-side GPRS


about 15 months late (03/01/2023)

GPRS support on the mobile station (phone) side


16 issues   (6 closed10 open)

MS-side GPRS implementation

Project description

An open source GPRS implementation for OsmocomBB. Can demonstrate GRPS attach, PDP
context establishment and the exchange of uplink and downlink user IP data with a GPRS network.

A sample pcap containing the related messages can be found here: gprs_attach.pcapng.gz
The sequence diagrams of all primitives required between layers can be found at 3GPP TS 24.007 Annex C "GPRS-Services sequence diagram".

Project architecture

Here we have the overall project architecture and the state of implementation.

I created a draft layer diagram using, see the attachments.
The "ardc_darc_gprs_arch.drawio" can be uploaded and edited there.
Suggestions/corrections are welcome (FIXME section below).

Lower layer details

  • the setup consists of a few threads
    • a lower rx-thread that keeps the time by handling SCH bursts and ensures ts alignment
    • the upper rx thread that also is the select "main loop" that demods the bursts and handles the communication with upper layers
    • ctrl if thread that asynchronously handles ctrl commands which can't be submitted from libusb threads in the bladerf case
    • a tx thread that modulates and submits the bursts
    • in case of uhd a few more threads, 9 in total.
  • current target is a raspi 4 running at max cpu freq without any power save, with isolated core 1+2 (0+3 work as usual), other threads are distributed across non isolated cores.
    • arbitrary choice, rpi4 usb is known good, cpu is sufficient
    • yes, this can run as is on any system with 4 cores without configuring anything, it will just not work reliably.
  • latency excluding usb is > 1 ts, since the sdr buffer is 1ts < size <2 ts so the average case is 1-2ts latency including demodulation until data hypothetically reaches the l1 socket to upper layer apps, decoding is basically free.
    • usb3 packet size is 1024 -> min blade usb transfer is 1020 samples
    • uhd transfer size has to aligned to 8 and 24 bytes but not a multiple of 1024.. so it can be tuned, but not to gsm burst sizes.

GAPK (GSM Audio Pocket Knife) back-end intergation



5 issues   (2 closed3 open)

GAPK Integration

GAPK (GSM Audio Pocket Knife) is a FFmpeg like project focused on GSM related codecs (HR/FR/EFR/AMR) and various formats. Since the libosmogapk was introduced, it has become possible to link OsmocomBB against it and use its API for audio processing, i.e. for both voice capture and playback.

The initial working implementation can be found in a separate branch (fixeria/audio).

PHY support

Both trxcon and VIRT-PHY do forward TCH frames to the higher layers (e.g. mobile) by default, while Calypso-based phones can handle them either within DSP (both regular phone's mic and speaker are involved), or also forward them via L1CTL. The forwarding behavior can be enabled using L1CTL_TCH_MODE_REQ message and its AUDIO_TX_TRAFFIC_REQ | AUDIO_RX_TRAFFIC_IND flags.

Why GAPK integration is important?

Well, at the moment the state of voice support in the higher layers, especially in the mobile application, is limited. There is incomplete implementation of MNCC-socket handling, including forwarding of TCH frames, but it is very limited (for example, only TCH FR codec is supported).

With GAPK it is pretty easy to fill the gap, and implement audio / voice processing back-end for mobile application. In particular, back-end implementation assumes the following features:

  • voice capture and playback (via ALSA),
  • frame coding for GSM specific codecs,
  • PHY specific format (e.g. TI) handling,
  • ECU (Error Concealment Unit),
  • RTP support.
Add picture from clipboard (Maximum size: 48.8 MB)