<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">Hi,</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">       We have been working on the handover feature in
OsmocomBB and have managed to make some progress including SB/BSIC
detection in dedicated mode which was not previously being
successfully done in firmware. I wanted to share it and seek
guidance on the last bit of handover implementation on which
we are stuck. I hope someone would be able to help us or make use of our
work.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">We
took code related to handover from the osmocom-bb jolly branch by
manually adding/deleting stuff in the master branch as updating to
the latest copy was giving us issues. We added code from the “Safely
change TPU offset on TS change or sync change” commit till the “Use
only sel_si for information about the current cell” commit. Using
the handover code in the jolly branch and after making the changes
explained below we were able to obtain the handover command from the
BTS. The synchronized handover case works sometimes though still not
every time, however the non-synchronized case doesn't work at all as
we are not able to get the physical information command from the new
cell. I'll explain the changes/additions we made to achieve this.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">Firstly,
we noted that in dedicated mode SB burst was not being detected.
Changes were required at three main places in order to correctly
perform FB/SB detection:</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">- It
was seen that the results for SB were being read from DSP API
location dsp_api.db_r->a_sch which is for the idle mode. The
results had to be read from the dsp_api.ndb->a_sch26 location for
the dedicated case if TCH_SB_DSP_TASK is used.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">-
After reading the FB we needed to update the quarter-bit offset of
the TPU using the TOA of the FB to sync it with the start of frame of
the neighbour cell in order to catch the SB (by changing the vaule of
l1s.tpu_offset using the TOA of the FB).</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">-
Frequency compensation needed to be performed using the afc_correct
function before reading the SB.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">* We
actually kind of cheated a bit by adding 3 frames to the original
idle frame in order to give us more time to perform FB/SB detection
including the synchronizations mentioned above. This was because we
weren't that proficient with the code and someone with more
understanding could do this better. The call did not get dropped. We
used the initial added “idle” frame to perform the quarter-bit
and frequency compensation which was reversed in the idle frame with
the response function to tune back to the serving cell.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">These
things, when added to the code did the trick and BSIC of the
neighbours was obtained.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">Once
the BSICs were decoded the measurement report sent to the BTS became
meaningful and the handover command was received. Upon receiving
handover command, access bursts needed to be sent on the new channel
which again was not currently being implemented properly as in order
to tune to the new cell we needed to know its quarter-bit offset for
start of frame, frequency compensation and absolute frame number
which were not previously being obtained. Now that we were able to
detect FB and SB these values were stored for the neighbours
following detection of these bursts and were used to tune to a
neighbour cell in case of a handover to it before the sending of
access bursts. However, here is where we are stuck. We were expecting
a physical information message following the access bursts but were
not able to receive it due to which the handover failed. If only that
could be achieved we believe handover should be successful.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">Either
we are not syncing properly to the new cell or we might not be
following GSM protocol properly. We also might not be reading the
FACCH properly for physical information message after tuning to the
new cell as we couldn't really understand that bit very well. We
wanted someone expertise on this matter and were hoping our work could
be of use. We were more interested in getting the work done
first up.</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">Best
Regards,</p>
<p class="m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:100%">M. Awais Aslam</p></div></div></div>