MS-side GPRS implementation¶
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".
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.