layer3 work / issues

[Harald Welte]

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
-- 
- 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)