MS-side GPRS » History » Version 11
pespin, 04/24/2023 10:44 AM
1 | 1 | fixeria | h1. MS-side GPRS implementation |
---|---|---|---|
2 | |||
3 | h2. Project description |
||
4 | |||
5 | 5 | pespin | An open source GPRS implementation for OsmocomBB. Can demonstrate GRPS attach, PDP |
6 | context establishment and the exchange of uplink and downlink user IP data with a GPRS network. |
||
7 | 1 | fixeria | |
8 | 9 | pespin | A sample pcap containing the related messages can be found here: attachment:gprs_attach.pcapng.gz |
9 | 8 | pespin | The sequence diagrams of all primitives required between layers can be found at 3GPP TS 24.007 Annex C "GPRS-Services sequence diagram". |
10 | |||
11 | 1 | fixeria | h2. Project architecture |
12 | |||
13 | Here we have the overall project architecture and the state of implementation. |
||
14 | |||
15 | I created a draft layer diagram using https://draw.io, see the attachments. |
||
16 | The "ardc_darc_gprs_arch.drawio" can be uploaded and edited there. |
||
17 | 2 | fixeria | Suggestions/corrections are welcome (FIXME section below). |
18 | 1 | fixeria | |
19 | 11 | pespin | !ardc_darc_gprs_arch.v5.png! |
20 | 2 | fixeria | |
21 | 6 | Hoernchen | h2. Lower layer details |
22 | |||
23 | * the setup consists of a few threads |
||
24 | ** a lower rx-thread that keeps the time by handling SCH bursts and ensures ts alignment |
||
25 | ** the upper rx thread that also is the select "main loop" that demods the bursts and handles the communication with upper layers |
||
26 | ** ctrl if thread that asynchronously handles ctrl commands which can't be submitted from libusb threads in the bladerf case |
||
27 | ** a tx thread that modulates and submits the bursts |
||
28 | ** in case of uhd a few more threads, 9 in total. |
||
29 | * 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. |
||
30 | ** arbitrary choice, rpi4 usb is known good, cpu is sufficient |
||
31 | ** yes, this can run as is on any system with 4 cores _without_ configuring anything, it will just not work reliably. |
||
32 | * 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. |
||
33 | ** usb3 packet size is 1024 -> min blade usb transfer is 1020 samples |
||
34 | 2 | fixeria | ** 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. |