Hi Andreas,

some comments regarding your issues.txt:

must random value in chan_request change on every resend or only on every RR establishment? (currently it changes on every RR establishment only.)

as far as I know, it has to change on every retransmission. Dieter is probably the person who knows all RACH aspects in detail, maybe he can comment on this.

must be expanded: struct osmocom_ms:

no problem here, expand it how you see fit. I just generally prefer caller-allocated structures to callee-allocated ones, and I'd like to use static allocation whenever possible. So if there's only one 'struct rrlayer' per ms, then we should simply include 'struct rrlayer' as sub-structure of 'struct osmocom_ms', rather than having two structures and pointers between them.

OpenBSC: if tx-msg fails during process, the msg must be freed to avoid memory leak.

I don't understand, can you please explain this further?

random acces via RSL?

I think we simply add some new / non-standard primitives, as it does not have any notion of RACH bursts.

It might also be possible to encode it as UNIT DATA REQUEST for channel (chan_nr) RACH (CCCH uplink), but then we still cannot specify details like at which frame number, etc. From what I can see, your RSL_MT_RAND_ACC_REQ approach looks fine to me. As a minor improvement we could call it RSLms_MT_RAND_ACC_REQ to indicate that it is our custom RSLms message and nothing specified in the original RSLms spec.

Cheers, Harald