handover: for intra-cell HO, use RR Assignment Command, not RR Handover Command
Handover Decision algorithms may decide to do a re-assignment within the same cell.
In practical tests, some time ago, I noticed that using the RR Assignment Command wasn't working here.
Hence we currently send an RR Handover Command referencing the same cell, which is kind of weird.
Now I saw one reason why Assignment doesn't work for handover: in bsc_api.c, in handle_ass_compl(),
we receive the RR Assignment Complete message and dispatch an SS_LCHAN signal S_LCHAN_ASSIGNMENT_COMPL.
However, throughout osmo-bsc, there is not a single handler for S_LCHAN_ASSIGNMENT_COMPL.
This might be another casualty from the split-off from osmo-nitb.
Anyway, it doesn't make sense to me that we send an S_LCHAN_ASSIGNMENT_COMPL,
while the remaining code triggers bsc_subscr_conn_fsm.c GSCON_EV_* events directly.
Fix: Actually handle RR Assignment Complete during handover,
and send RR Assignment Command instead of RR Handover Command for intra-cell HO.
This is not high priority, and should wait until after intra-BSC handover has rippled through the lchan allocation code.
#2 Updated by neels over 2 years ago
The new FSM implementations have been merged to osmo-bsc master, but we are still using an RR Handover Command to re-assign an lchan within the same cell; it works ok, but an RR Assignment Command would make more sense. The code is now ready to change this and use the Assignment FSM (?) or use RR Assignment Command from handover FSM (?) for handovers where source and target cells are identical.
#6 Updated by neels about 2 years ago
actually, now I found a spec snippet that might be interpreted to suggest to rather use the Handover Command:
3.1.6 Internal Intra-Cell Handover Procedure The definition of internal intra cell handover is given in sub-clause 5. It is optional that a BSS support internal intra-cell handover. However if it is supported, it should be as follows: It should be possible to inhibit internal intra-cell handover at an BSS that supports it by operation and maintenance command. Internal intra-cell handover occurs between channels on the same cell. It is decided and executed autonomously by the BSS, so that no message is generated at the BSS-MSC interface, until the completion of the handover execution, when the BSS sends a HANDOVER PERFORMED message over the SCCP and terrestrial resources that are presently assigned to that call. Changes in type of resources (for instance channel rate change, speech version change, ciphering algorithm change) are indicated in the HANDOVER PERFORMED message.
Compare to 184.108.40.206 describing the successful Assignment operation:
If an intra-BSS cell change has occurred during the assignment, the new cell identity is included in the ASSIGNMENT COMPLETE message and a HANDOVER PERFORMED message is not required.
The first snippet suggests that a Handover procedure using a Handover Command does exist for changing lchans within the same cell.
The second snippet suggests that during Assignment, no Handover Performed message is needed; but at the same time, the second snippet suggests that even during an Assignment, the BSS may decide to change the cell.
In summary, it seems to me that both are possible and we can choose not to bother and just use RR Handover Command.
- the TDMA timing of the old and new channel are identical (guaranteed within one BTS, but implementation option if other BTS have synchronized TDMA clocks
- the timing advance to be used when establishing the new channel (known within same BTS as it is identical to the old; typically not known for other BTSs unless you happen to be handing over between two sectors of the same site and hence the distance is identical)
For all other cases, HANDOVER must be performed, because the MS will re-sync to the frame clock and send access bursts to establish the timing advance.