OsmocomBB

h1. MS-side GPRS implementation

h2. 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.

The sequence diagrams of all primitives required between layers can be found at 3GPP TS 24.007 Annex C "GPRS-Services sequence diagram".

h2. 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).

!ardc_darc_gprs_arch.v3.png!

h2. 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.