Cellular Network Infrastructure » Radio Access Network » OsmoPCU

I now wonder how difficult it would be to solve the problem: As far as I understand in this situation, the TBF is created and waits for confirmation, but it has no TLLI yet.

What we could do is to generate a unique 32 bit identifier each time we crate a TBF. This could be just a counter. Then each TBF would have its unique serial number and we would use that as an identifier.

The relevant function calls are:

src/bts.cpp:                            pcu_l1if_tx_pch2(bts, immediate_assignment, plen, true, tbf->imsi(), tbf->tlli());
src/gprs_rlcmac.c:              pcu_l1if_tx_pch2(bts, paging_request, plen, false, imsi, GSM_RESERVED_TMSI);
src/bts.cpp:                    pcu_l1if_tx_agch2(bts, bv, plen, tbf->tlli(), false);
src/bts.cpp:                    pcu_l1if_tx_agch2(bts, bv, plen, tbf->tlli(), false);
src/bts.cpp:                            pcu_l1if_tx_agch2(bts, immediate_assignment, plen, true, tbf->tlli());

In almost all cases (gprs_rlcmac.c is about paging), I see that the TLLI is returned by a method of the tbf object. Its simple to change this to tbf->id() or something.

When the confirmation comes back from the BTS, it ends up in bts.cpp:bts_rcv_imm_ass_cnf(). This function looks up the ms object by the the TLLI and then gets the dl_tbf object from that ms object. The dl_tbf object then gets a signal TBF_EV_ASSIGN_PCUIF_CNF dispatched, but there is not data given. Its just the signal.

When we use a unique TBF id, then the things will be even get simpler. we can just resolve the TBF by its ID by iterating through the trx->dl_tbfs list.

dexter wrote in #note-1:

I now wonder how difficult it would be to solve the problem: As far as I understand in this situation, the TBF is created and waits for confirmation, but it has no TLLI yet.

What we could do is to generate a unique 32 bit identifier each time we crate a TBF.

No, you want to generate a unique identifier which matches a given request msg, not a TBF. So you basically have a seq_nr you increment each time you submit a msg.

That can be implemented by having a llist of enqueued requestes waiting for confirmation, where you store the msg_id, and a pointer to whatever data struct you require, such as a TBF pointer, an MS pointer, etc.
When you receive the confirmation, you call a function to process it.
OFC one needs to remember to remove pending entries from the llist eg. when the TBF is freed, in order to avoid accessing the freed TBF pointer.