OsmocomBB SDR PHY - (E)GPRS protocol stack implementation

No issues for this version

GPRS (General Packet Radio Service) is a packet-switched cellular technology, which is used in
2G and 3G networks for transmitting IP packets to external networks such as the Internet. EGPRS
stands for "Enhanced GPRS", a GPRS based technology that allows improved data transmission
rates. The aim of this task is to get working mobile station implementation of GPRS protocol stack
and extend the GSM burst transceiver part of the project with ability to send/receive GPRS and
EGPRS signals.
  • physical layer (L1) modification in order to support packet switched communication (8-psk
    detection modulation and demodulation support for EGPRS, channel coding/decoding, TBF
    (Token Bucket Filter) scheduling)
  • implementation of the higher protocol layers (RLC/MAC, LLC, SNDCP)
  • composing a shared library of the existing GPRS related code in OsmcomBB
  • implementation of the transmit capabilities
  • implementation of host utilities (Packet capture (sniffer) utility, GPRS modem application)
  • tests (unit tests, conformance tests)

OsmocomBB SDR PHY - Ability to run GSM network on any frequency

No issues for this version

Since OsmocomBB does support SDR PHY now, the working frequency range is only limited by hardware capabilities. In other words, the "ARFCN -> frequency" calculation may be modified to add a constant frequency offset, so this will allow one to run both base stations and (OsmocomBB-based) mobile stations on any frequency (e.g. in 2.4 GHz WiFi band)!

Of course, regular GSM phones are not able to "see" any networks outside the known predefined ranges (e.g. GSM-900, DCS-1800), so they wouldn't be able to camp to a network running on some shifted frequency. So we have the following use cases in our mind:

  • TODO
  • TODO
  • TODO

OsmocomBB SDR PHY - Extended SDR hardware compatibility

No issues for this version

Currently the GSM burst transceiver used by the project works with UHD (Universal Hardware
Deriver) compatible devices like Ettus USRPs and Fairwaves UmTRX. It is desirable to have
support for at least one additional cheaper SDR devices (like LimeSDR or LimeSDR-Mini).
  • implementing stream tags forwarding in GNU Radio blocks representing targeted SDR
  • porting of the L1 transceiver to targeted SDR platform(/s) (deliverable: source code,
    demonstration that it works)

OsmocomBB SDR PHY - Frequency hopping

No issues for this version

A BTS (Base Transceiver Station) on the GSM radio interface may use frequency hopping, that
poses additional difficulty to transmit and receive GSM signals on the mobile side. The aim of this
subtask is to implement frequency hopping for a GSM mobile station.

  • implementing transmission of GSM bursts according to a hopping sequence (deliverables:
    code + plot(/s) showing frequency of transmitted bursts)
  • implementing reception of GSM bursts that follows frequency hopping (deliverables: code +
    decoded messages from the signal with hopping)
  • extending the control interface between gr-gsm and Osmocom-BB with ability to
    send/change hopping parameters (deliverable: code)
  • testing the mobile station with a GSM BTS supporting frequency hopping (deliverable:
    protocol traces in Wireshark)

GAPK (GSM Audio Pocket Knife) back-end intergation


3 issues   (0 closed — 3 open)

GAPK Integration

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

Some initial work around this was already done, and has been published 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 behaviour 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.

OsmocomBB SDR PHY - Improvement of the higher layers of OsmocomBB


7 issues   (1 closed6 open)

The OsmocomBB project provides an Open Source implementation of the higher layers of the mobile-side GSM protocol stack, which at the moment allows a end-user to make voice calls, and exchange SMS messages. But some important parts are still missing, so the aim of this task is to fill this gap:

OsmocomBB SDR PHY - Measurements and control loops

No issues for this version

GSM mobile stations usually do perform measurements of timing, frequency and signal power while being camped on some BTS. The measurements are used for controling mobile phone parameters (such as both transmit and receive gains, signal transmission timings, etc.). The aim of this milestone is to implement the "must have" measurement capabilities and control loops.

  • Automatic TX to RX delay measurement
  • Calibrated power measurement
  • AGC (Automatic Gain Control) for the Receiver
  • TX power control loop
  • Timing advance control loop

Also see:

OsmocomBB SDR PHY - Physical SIM-card interface

No issues for this version

Unlike a regular phone, the SDR hardware has no SIM (Subscriber Identity Module) slot. It's only possible to use virtual (emulated) SIM-card in mobile application at the moment. This limitation prevents one from being able to use regular SIM-cards, hence from being able to interact with commercial GSM networks using the SDR PHY.

The idea of this task is to implement a PC/SC based interface to interact with a physical SIM-card.

OsmocomBB SDR PHY - Testing, tuning and extending the Receiver module of GR-GSM

No issues for this version

The purpose of this subtask is to find out how good / bad current implementation of the MLSE (Maximum Likelihood Sequence Estimation) channel equalization algorithm is and to add another equalization algorithm that has lower computational complexity.

Currently the following sub-tasks are work in progress:

  • Receiver: sample / burst buffering problem (see #3422)
  • Receiver: hard-coded GSM 05.02 channel configuration (see #3423)

Scheduled sub-tasks:

  • Virtual low-level UHD-based interface (for testing and simulation)
    • BER (Bit Error Rate) simulations
    • performance optimization

Cellular Network Infrastructure - Virtual GSM Load Testing

Load testing with many (thousands) of virtual phones


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