This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)