Sometimes sending one Access Burst is not enough, so we need to repeat
sending it a few more more times changing the 3 LSBs randomly. This
is what we already do in the mobile app, but not in the modem app.
* Rename GRR_EV_RACH_{REQ,CNF} to GRR_EV_CHAN_ACCESS_{REQ,CNF}.
* Rename VTY command 'grr tx-chan-req' to 'grr start-chan-access'.
* Add an intermediate state GRR_ST_PACKET_ACCESS.
** The GRR_EV_CHAN_ACCESS_REQ transitions to this state.
** One RACH.req gets transmitted when entering this state.
** The GRR_EV_CHAN_ACCESS_CNF confirms transmission of a RACH.req.
** Upon the timeout (300 ms) expiry, a loop state transition happens.
** After 3 loop-transitions, transition to GRR_ST_PACKET_NOT_READY.
Change-Id: Iab6d9147f6e0aeb99239affacf318a3897fd6ffe
Related: libosmo-gprs.git If0de3ed86b1e2897d70183f3b0f4fbfd7d2bda80
Related: OS#5500, OS#6131
Before this patch, the RTS:ind was crafted up in the stack when
receiving the DL_BLOCK.ind. This created some problems since the
internal low level state has to be updated in between signalling
DL_BLOCK.ind and RTS.ind, as there's a fn-advnace of one block between
those 2 signals (hence the timeslot allocation has to be applied at the
time when the fn-advance is applied).
This is actually not fixing the whole issue, since there's several
timeslots and hence the following events will have the internal timeslot updated
during the event in the middle, hence potentially causing problems in the
remaining TS:
DL_BLOCK.ind(FN=N, TS=1), RTS.ind(FN=N+4, TS=1), DL_BLOCK.ind(FN=N, TS=2)
In any case, this decoupling already improves the situation and is step
needed anyway towards fully fixing the problem (by, for instance,
maintaining a timeslot state duplicated both for DL and Ul directions,
since they drive based on differnet FN time (1 PDCH block).
Change-Id: I1494e0aac7555f6e01b4b435b77140afc42c098e
Vadim Yanitskiy
Pau Espin