Attention is currently required from: jolly, pespin, fixeria.
4 comments:
Commit Message:
Patch Set #1, Line 7: gprs_rlcmac: also use direct TLLI PCUIF for paging macblocks
not sure what "paging backblocks" means here.
I just mean a MAC block with a paging message inside. We generate those with write_paging_request() and send them to osmo-bts as a whole. Osmo-bts then does not interpret them any further it just sends them.
Patch Set #1, Line 28: OS##5927
only one `#` please
Done
File src/gprs_rlcmac.c:
Patch Set #1, Line 20: #include <osmocom/core/bitvec.h>
why adding this header?
I had problems getting the bitvec type recognized but in the end it was just a missing struct in the function signature. I forgot to remove this one again.
Patch Set #1, Line 49: mi->tmsi
You're saying TLLI, but actually passing a TMSI -- this is not always the same thing. […]
gprs_rlcmac_paging_request() is called from gprs_bssgp_pcu.c:gprs_bssgp_pcu_rx_paging_ps(), which calls get_paging_ps_mi() to generate the mi. And this mi is always of type GSM_MI_TYPE_TMSI. So at least in that regard we should be fine. (we might consider to add an OSMO_ASSERT)
As far as I am aware use the same the same identifier in TLLI and TMSI even though both could be different. However, after all, we do not do anything different than we did before since the MAC block we generate is also based on the same value. When the confirmation comes back, everything seems to end up in bts.cpp:tlli_from_imm_ass(), where we either use the direct TLLI value or extract the value from the MAC block.
Whet confuses me though is that tlli_from_imm_ass() is apparently not able to handle paging_request macblocks even though osmo-bts sends confirmations for those. This is really confusing. Do you have an idea? I am a bit lost here.
To view, visit change 32694. To unsubscribe, or for help writing mail filters, visit settings.