Feature #6150
openPCUIF: Use unique identifiers instead of the TLLI as msg_id.
0%
Description
When the PCUIF sends a MAC block for PCH (or AGCH) it may request a conformation when the MAC block is sent. For the conformation an uint32_t message id (msg_id) is used. At the moment we use the TLLI as message identifier. However, on the one hand side the TLLI may not be unique, and on the other hand the TBF may not have a TLLI assigned yet. This is in particular the case when the MS is just attaching to the network and has not completed the GMM attach phase yet.
A solution would be to somehow generate a truly unique identifier inside the PCU and use it when sending MAC blocks through the PCUIF. When the receiving end responds with the confirmation we will have to match the identifier back to the TBF to which it belongs.
Updated by dexter 8 months ago
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.
Updated by pespin 8 months ago
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.
