Project

General

Profile

Roadmap

MS-side GPRS

open

Due in about 3 months (03/01/2023)

GPRS support on the mobile station (phone) side

15%

7 issues   (0 closed — 7 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.

Project architecture

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

I created a draft layer diagram using https://draw.io, 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.

FIXME

  • Typo: s/SN/SM/

GAPK (GSM Audio Pocket Knife) back-end intergation

open

24%

5 issues   (0 closed — 5 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.

Cellular Network Infrastructure - Virtual GSM Load Testing

open

Load testing with many (thousands) of virtual phones

80%

4 issues   (2 closed2 open)

Virtual GSM Load Testing

This is about development of Load Testing Setup to demonstrate OsmoBSC functionality and performance at >= 200 TRX, >= 100 BTS and thousands of MS.

  • Development of primitive-based asynchronous interface to OsmocomBB ├ómobile├ó program, together with script language (e.g. LUA) bindings for cellselection, location update, SMS and voice calls.
  • Development of voice frame support to OsmocomBB virt_phy, OsmocomBB mobile and osmo-bts-virtual to simulate voice/user plane in addition to control/signaling plane.
  • Development of software to manage (configure, start, monitor, stop) thousands of OsmocomBB mobile instances as well as hundreds of osmo-bts-virtual instances
  • Creation + Documentation of corresponding test suite for automatic execution of load testing
Add picture from clipboard (Maximum size: 48.8 MB)