7 Apr
2010
7 Apr
'10
9:47 a.m.
Hi Andreas,
some comments to your issues.txt:
How do we send MEASUREMENT RESULTS to RSL? (maybe
RSL_MT_MEAS_RES)
what triggers the sending? Or do we just send it from time to time to
layer 1 where it is stored and sent when the time is right? (Then we
might get something like RSL_MT_MEAS_CNF, so we can send the next one,
if we have new measurements available, otherwhise the L1 will use the
old measurement results and resends them without confirming it.)
measurement results are sent on the SACCH. The Layer1 has independent
transmit queues for the main channel (SDCCH/TCH) and its associated
SACCH. So the L23 code needs to send the respective packet to a
chan_nr/link_id that indicates transmission over the SACCH.
In the GSM TS, there is a primitive by which L1 can indicate that it
needs the next L23 message for a given channel, which we don't implement
(as we're tunnelling L1CTL through HDLC/serial, the answer would never
be back before the next TDMA frame anyway).
My suggestion would be: Have a fixed SACCH queue depth of 1 or 2 in
L1CTL, and every time we actually dequeue the frame (i.e. send it to the
DSP), send an indication of the current queue depth up to L23. We
should do this for both the main and the ACCH queue so higher layers can
implement some kind of flow control if they want.
I need some RACH primitives like:
- RACH request (tx_ph_rach_req already exists) including value and
offset of RACH slot from now.
What exactly do you mean with 'value and offset of RACH slot from now'?
As we're operating asynchronously "now" is not defined precisely. I
think if you simply tell the L1 that you want to transmit at a specified
GSM time (modulo 51), we can schedule it that way.
L23 should understand the current CCCH/BCCH layout and determine which
lsots are applicable for RACH burst transmission. They can then either
say "please transmit at this full gsm time (uint32_t of the frame
number)" or "please transmit in next multiframe at fn % 51 == X where X
is something specified by L23"
- RACH confirm, the RACK has been sent (with timeslot
where is was sent)
that should be relatively easy to add, I'll add it during the next days.
Meanwhile we can simply assume that it was sent at the timeslot as
requested.
Since RACH request must be queued in layer 1 until it
the right slot
is reached, I need to tell L1 to cancel it. Whenever I receive a
confirm, I schedule the next one until the maximum number has been
transmitted or until an IMMEDIATE ASSIGNMENT is received on CCCH.
I think we can ignore that for now. In the worst case, we send one more
RACH request than needed. I know this is dangerous if done by many
phones on real networks, but for our current goal of "getting something
working in our own gsm test network" this is the kind of shortcut we can
take.
I know your development style is very different. You seem to be trying
to implement something thats fully compliant with the spec. I usually
try to take a more incremental/iterative approach. Make something work
first, and then iteratively improve/complete it. I hope you can live
with the fact that at least for now, L1 doesn't have this support. If
you want, we can already define the L1CTL message for it but simply
ignore it on L1 until its implemented.
RACH request on RSL:
Does it make sense to put RACH request to the set of RSLms primitives?
(i.e. RSL_MT_CHAN_REQ, not RQD!, RSL_MT_CHAN_CNF, RSL_MT_CHAN_CAN)
What do you say?
I think we should mark them explicitly as RSLms_MT_* to make it obvious
that it is non-standard RSL. Otherwise, I agree. "CAN" for "CANCEL"
is
probably causing misunderstanding, lets just write the full word.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)