Attention is currently required from: neels, pespin, dexter.

fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-pcu/+/31145 )

Change subject: bts: add IMMEDIATE ASSIGNMENT via PCH transmission ......................................................................

Patch Set 18: Code-Review-1

(1 comment)

File include/osmocom/pcu/pcuif_proto.h:

https://gerrit.osmocom.org/c/osmo-pcu/+/31145/comment/39be9e40_3c907ecb PS17, Line 280: uint8_t pgroup[3]; Wait a minute, I am confused by this field. It's named `pgroup`, so that means it's supposed to contain a paging group, right? But in reality it's just the last three digits of the IMSI converted to ASCII.

For some reason in osmo-pcu we convert these last three digits to ASCII, and then in osmo-bts (see `paging_add_imm_ass()`) we convert three ASCII bytes back to an integer add feed to `gsm0502_calc_paging_group()`.

I think this would then make using the struct at the BSC side more complicated

I haven't looked at the BSC's implementation of the relevant part, but I don't see how using ASCII instead of plain integers simplifies things either.

The thing is that this value ends up at extract_paging_group and this function does a str_to_imsi(imsi_digit_buf) with the value ...

So by sending a plain integer stored in `uint16_t` here we actually eliminate the need for `str_to_imsi()`.

If we can feed gsm0502_calc_paging_group() the pgroup value from here directly then we can use an uint16_t.

I am pretty sure we can, why not.

To summarize:

* I see no reason for using ASCII to carry the last three digits of IMSI, * so let's just send plain integer here, directly from `ms_paging_group()`. * I agree with Pau that we should simply use `uint16_t`. * Name the field `imsi`, it's not a paging group itself.