fairwaves HO patches

[Neels Hofmeyr]

On Tue, Feb 13, 2018 at 10:01:11PM +0300, Ivan Kluchnikov wrote:
[...]
> For tests, I called bsc_handover_start function from different parts of the
> code and for different states of the call and checked media and signalling
> after and during HO procedure.

Nice idea :)

> So one of the main improvement which should be implemented is an automated
> test suite for HO procedure which will cover all stages of the call.

Our TTCN-3 test suite is probably a good place to put this.
We also have the osmo-gsm-tester, to verify with real hardware.

> > >       gsm48_send_ho_cmd(ho->old_lchan, new_lchan, 0, ho->ho_ref);
> > >
> > > +     new_lchan->conn->in_handover = 1;
> > > +
> >
> > In current osmo-bsc master, we already set conn->ho_lchan before sending
> > out
> > the chan activation request. I'd actually assume setting the flag only now,
> > after the activ ack, is a bit too late?
> 
> 
> I set it right after gsm48_send_ho_cmd, because sending of HO CMD is the
> actual start of handover procedure (as I understand specs).

Ah, from the context of the original lchan, starting to be in handover probably
is at this point. But from the conn's perspective I'd like to think of it
starting to be in handover the moment we've decided that we want it to
handover, i.e. from bsc_handover_start(), where we initially choose the lchan
to handover to and start to chan-activ that. So ok, it's just a matter of
perspective.

> > >       /* start T3103.  We can continue either with T3103 expiration,
> > >        * 04.08 HANDOVER COMPLETE or 04.08 HANDOVER FAIL */
> > >       ho->T3103.cb = ho_T3103_cb;
> > > @@ -221,7 +230,8 @@ static int ho_chan_activ_ack(struct gsm_lchan
> > *new_lchan)
> > >       osmo_timer_schedule(&ho->T3103, 10, 0);
> > >
> > >       /* create a RTP connection */
> > > -     if (is_ipaccess_bts(new_lchan->ts->trx->bts))
> > > +     if (is_ipaccess_bts(new_lchan->ts->trx->bts) &&
> > > +                                     new_lchan->tch_mode !=
> > GSM48_CMODE_SIGN)
> > >               rsl_ipacc_crcx(new_lchan);
> >
> > Please explain ... what case / behavior is this fixing?
> > Do we ever see CMODE_SIGN handovers?
> > Would we also need to check for GSM48_CMODE_DATA_*?
> >
> 
> Yes, handover can be initiated in any mode of lchan and we saw handovers
> for lchans in GSM48_CMODE_SIGN mode.
> So I think we should be able to cover this case because I didn't find any
> mention in the specs that this case is prohibited for HO.
> I don't know if HO is allowed for CSD (GSM48_CMODE_DATA_*), it should be
> checked.
> But if it is prohibited for CSD, I think we should check and block it on
> the stage of bsc_handover_start or earlier.

So, what is CMODE_DATA, is it for PDCH / GPRS data?

As far as osmo-bsc is concerned, a timeslot used for data appears as "not in
use", osmo-bts leaves operation of PDCH to the pcu. I don't think receiving a
handover for a data ts is possible, because they are no lchans.

Or is CMODE_DATA something I don't know about yet? :)


[...]

Thanks for the remaining explanations, which help a lot to clarify.

FYI, one of my next tasks is to implement the inter-BSC handover part for
osmo-bsc, and it's likely that the MSC part for inter-BSC handover will follow
or go along with it; for which your patches and comments will be very helpful.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180223/d4909fb7/attachment.bin>