OsmocomBB MS-side GSM Protocol stack (L1, L2, L3) including firmware
https://osmocom.org/projects/baseband
Vadim Yanitskiy
6e1c82d298
In order to reflect the UL/DL delay caused by the premature burst scheduling (a.k.a. 'fn-advance') in a virtual environment, the Transceiver implementation now queues all to be transmitted bursts, so they remain in the queue until the appropriate time of transmission. The API user is supposed to call recv_data_msg() in order to obtain a L12TRX message on the TRXD (data) inteface, so it gets queued by this function. Then, to ensure the timeous transmission, the user of this implementation needs to call clck_tick() on each TDMA frame. Both functions are thread-safe (queue mutex). In a multi-trx configuration, the use of queue additionally ensures proper burst aggregation on multiple TRXD connections, so all L12TRX messages are guaranteed to be sent in the right order, i.e. with monolithically-increasing TDMA frame numbers. Of course, this change increases the overall CPU usage, given that each transceiver gets its own queue, and we need to serve them all on every TDMA frame. According to my measurements, when running test cases from ttcn3-bts-test, the average load is ~50% higher than what it used to be. Still not significantly high, though. Change-Id: Ie66ef9667dc8d156ad578ce324941a816c07c105 Related: OS#4658, OS#4546 |
||
|---|---|---|
| contrib | ||
| doc | ||
| include | ||
| src | ||
| .gitignore | ||
| .gitreview | ||