OsmocomBB

Additonally, the current scheduler is kind of timer driven, instead of being driven by rx frames or some sort of fn/tn indication, which also causes jitter, and the old osmo-bts/trx split approach basically duplicates channel layout knowledge, the trxcon scheduler knows which fn and tn to handle, so there is no reason to duplicate the decision logic/channel layout for the lower parts.

Hoernchen wrote in #note-3:

Additonally, the current scheduler is kind of timer driven, instead of being driven by rx frames or some sort of fn/tn indication, which also causes jitter, and the old osmo-bts/trx split approach basically duplicates channel layout knowledge, the trxcon scheduler knows which fn and tn to handle, so there is no reason to duplicate the decision logic/channel layout for the lower parts.

Here is a very first step towards this goal:

https://gerrit.osmocom.org/c/osmocom-bb/+/29954 trxcon: drop sched->clock_cb(), expose l1sched_trigger()

• a way to "be" the trxcon main loop
• the interface to access the scheduler for the one trx instance (itself) that matters to the ms-transceiver to check if the ts is active
• bidirectional calls into the transceiver to submit a tx burst, and to push a rx burst up after handling it
• same approach for ctrl message cmd/response

See https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/commit/2ecd9f698f90b9d00612384008bec08c14ed2b1d?style=split&whitespace=show-all for the current hack that shows the changes that are required (based on the OLD libosmocore, ctrl missing, still handled using sockets)

I am currently waiting for code review on some patches (see #note-7). Once merged, you can proceed with the integration as follows:

General¶

• Call trxcon_set_log_cfg() to initialize logging with desired categories (DLGLOBAL is used by default).
  • this is how trxcon does this: https://gerrit.osmocom.org/c/osmocom-bb/+/30101/2/src/host/trxcon/src/logging.c.

• Allocate a struct trxcon_inst using trxcon_inst_alloc(), then set both trxcon->phyif and trxcon->l2if.
  • Optionally set trxcon->gsmtap if you want osmo-trx-ms originated GSMTAP.

PHYIF abstraction¶

Related commits:

https://cgit.osmocom.org/osmocom-bb/commit/src/host/trxcon?id=c6324f89520fc8a003e091cbe17508c1aa67c65b
https://cgit.osmocom.org/osmocom-bb/commit/src/host/trxcon?id=5fbc7e50a9301cfc23ccb8bf85eccd0789f83a18

• Implement the following PHYIF shim functions (see how trxcon_main.c does this):

int trxcon_phyif_handle_burst_req(void *phyif, const struct trxcon_phyif_burst_req *br);
int trxcon_phyif_handle_cmd(void *phyif, const struct trxcon_phyif_cmd *cmd);
void trxcon_phyif_close(void *phyif);

• From your PHYIF implementation call the following functions (pass struct trxcon_inst * as priv):

int trxcon_phyif_handle_burst_ind(void *priv, const struct trxcon_phyif_burst_ind *bi);
int trxcon_phyif_handle_rsp(void *priv, const struct trxcon_phyif_rsp *rsp);

L1CTL interface¶

I guess you want your own L1CTL server implementation, which does not require osmo_select_loop()?
Currently libtrxcon intentionally does not include the L1CTL server and provides an abstract API.

https://cgit.osmocom.org/osmocom-bb/commit/src/host/trxcon?id=394793b1c1596d0c788d105ec874a67b8024fcd4

• Implement the L1CTL server (or simply take from https://cgit.osmocom.org/osmocom-bb/tree/src/host/trxcon/src/l1ctl_server.c).

• Implement the following L1CTL shim functions (see how trxcon_main.c does this):

int trxcon_l1ctl_send(struct trxcon_inst *trxcon, struct msgb *msg);
void trxcon_l1ctl_close(struct trxcon_inst *trxcon);

• Call the following function from your L1CTL server implementation:

int trxcon_l1ctl_receive(struct trxcon_inst *trxcon, struct msgb *msg);

Eric has uploaded the state-of-art osmo-trx-ms:

https://cgit.osmocom.org/osmo-trx/log/?h=mstx_newtrxcon

In PM he told me he's having a problem with the RTR and Uplink burst handling. According to him, the scheduler complains about bursts received for disabled timeslots. I could not reproduce this with hacked fake_trx.py so far. The only potentially causing this thing I noticed so far is how the actual RTR.ind is sent:

@@ -128,29 +162,32 @@ SoftVector *upper_trx::pullRadioVector(GSM::Time &wTime, int &RSSI, int &timingO
        const auto is_sch = gsm_sch_check_ts(burst_time.TN(), burst_time.FN());
        const auto is_fcch = gsm_fcch_check_ts(burst_time.TN(), burst_time.FN());

+       // trxcon::trxcon_phyif_rtr_ind i = { static_cast<uint32_t>(burst_time.FN()),
+       //                                 static_cast<uint8_t>(burst_time.TN()) };
+       // trxcon::trxcon_phyif_rtr_rsp r;
+       // trxcon_phyif_handle_rtr_ind(trxcon::g_trxcon, &i, &r);
+       // if (!(r.flags & TRXCON_PHYIF_RTR_F_ACTIVE))
+       //      return false;

Note that the RTR.rsp (trxcon::trxcon_phyif_rtr_rsp) is not initialized here. I am not 100% sure, but I doubt C++ does implicit struct initialization. You may need to zero-initialize it. From the API usability point of view, it might be more handy if trxcon_phyif_handle_rtr_ind() would do initialization for the caller?

BTW, I just stumbled upon Figure 5.1 in 3GPP TS 44.004, defining the L1 PHY FSM. The trxcon_fsm I implemented recently is pretty much what 3GPP defines, with a few insignificant differences (e.g. separate states for DCCH and PDCH, separate state for power scanning). Looking at the reference FSM state diagram I submitted a few patches with the improvements for the trxcon_fsm:

https://gerrit.osmocom.org/c/osmocom-bb/+/30309 trxcon: add a spec. reference for the trxcon_fsm
https://gerrit.osmocom.org/c/osmocom-bb/+/30315 trxcon: trxcon_fsm: disallow invalid state transitions [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30316 trxcon: trxcon_fsm: shorten DCCH related event names [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30317 trxcon: trxcon_fsm: separate handling of TRXCON_EV_DCCH_EST_REQ [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30318 trxcon: trxcon_fsm: permit loop DCH transitions [NEW]
https://gerrit.osmocom.org/c/osmocom-bb/+/30319 trxcon: trxcon_fsm: permit direct {TCH,DCCH}/PDCH transitions [NEW]

fixeria wrote in #note-16:

Eric has uploaded the state-of-art osmo-trx-ms:

https://cgit.osmocom.org/osmo-trx/log/?h=mstx_newtrxcon

In PM he told me he's having a problem with the RTR and Uplink burst handling. According to him, the scheduler complains about bursts received for disabled timeslots. I could not reproduce this with hacked fake_trx.py so far.

I think I found a more serious problem in 9b6db11ee7fcc17a7960ea1a41ebdd69957c3bae (current HEAD):

+       if (pullRadioVector(burstTime, RSSI, TOA)) {
+               // trxcon::trx_data_rx_handler(trxcon::trxcon_instance, (uint8_t *)&response);
+               trxcon::trxcon_phyif_burst_ind bi;
+               bi.fn = htonl(burstTime.FN());
+               bi.tn = burstTime.TN();
+               bi.rssi = RSSI;
+               bi.toa256 = htons(TOA);
+               bi.burst = (sbit_t *)demodded_softbits;
+               bi.burst_len = sizeof(demodded_softbits);
+               // trxcon_phyif_handle_clock_ind(trxcon::g_trxcon, bi.fn);
+               trxcon_phyif_handle_burst_ind(trxcon::g_trxcon, &bi);

You are converting between the host and network byte order when using the PHYIF API. This is not required and is actually wrong, because libtrxcon is using the native byte order internally. This is only required when communicating with other processes over L1CTL or TRXD. Apparently increasing the trxcon's logging levels would have shown weird Fn/Tn numbers? Anyway, you need to remove all hton[sl]/ntoh[sl] calls.

P.S. It would have been a lot easier to comment on you patches if they were in Gerrit.

All patches have been merged, my part of this ticket is done.

There was an issue reported by Hoernchen about an endless make loop when trying to build trxcon as a submodule. Here is a single-line patch fixing the problem:

https://cgit.osmocom.org/osmo-trx/commit/?h=fixeria/ms&id=02f65668559f88c0c715e43728b794b028a9f844

Unfortunately I am still unable to build osmo-trx-ms, specifically the UHD variant. The linker fails with:

/usr/bin/ld: ms/osmo_trx_ms_uhd-ms_rx_lower.o: in function `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .resolver]':
/home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .avx]'
/usr/bin/ld: /home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .sse4_2]'
/usr/bin/ld: /home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .sse3]'
/usr/bin/ld: /home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .sse2]'
/usr/bin/ld: /home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .sse]'
/usr/bin/ld: /home/fixeria/projects/osmocom/osmo-trx/Transceiver52M/ms/ms_rx_lower.cpp:344: undefined reference to `detect_burst(std::complex<float> const*, std::complex<float>*, int, char*) [clone .default]'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:920: osmo-trx-ms-uhd] Error 1

I am giving up. No luck even after fixing stuff here and there. See other patches in:

https://cgit.osmocom.org/osmo-trx/log/?h=fixeria/ms

fixeria wrote in #note-20:

Unfortunately I am still unable to build osmo-trx-ms, specifically the UHD variant. The linker fails with: [...]

Actually, building with CC=clang CXX=clang++ works. Looks like GCC is not happy about something?

On Wed, Nov 30, 2022 at 10:28:09AM +0000, fixeria wrote:

Actually, building with CC=clang CXX=clang++ works. Looks like GCC is not happy about something?

let me clarify that the standard C/C++ compiler in Osmocom is gcc/g++.
If it also builds with other compilers, fine, that's most welcome in
addition to gcc All our infrastructure for build validation, etc. is
runnig gcc, which should be generally known.

Those are leftover debug macros related to xray tracing that will be removed as soon as it's pushed to gerrit.