<div dir="ltr">Dear Neels,<div><br></div><div>Thanks for the response.</div><div><br></div><div><span style="font-size:12.8px">> Osmocom lives by contribution. If you have implemented useful parts that we</span><br style="font-size:12.8px"><span style="font-size:12.8px">> don't support yet, please submit them back to us -- that would be highly</span><br style="font-size:12.8px"><span style="font-size:12.8px">> appreciated.</span><br style="font-size:12.8px">> <a href="http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches" rel="noreferrer" style="font-size:12.8px" target="_blank">http://osmocom.org/projects/<wbr>cellular-infrastructure/wiki/C<wbr>oding_standards#Submitting-Pat<wbr>ches</a><br></div><div><br></div><div>I have already uploaded the code which could be find here:</div><div><br></div><div>        <span style="font-size:12.8px">  </span><a href="https://gerrit.osmocom.org/5490" rel="noreferrer" style="font-size:12.8px" target="_blank">https://gerrit.osmocom.org<wbr>/5490</a></div><div><br></div><div><span style="font-size:12.8px">> I'm currently working on handover, though my attention is (should be) more on</span><br style="font-size:12.8px"><span style="font-size:12.8px">> the HO decision making process: trigger handover due to load considerations.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> In the process though I am touching and testing the stock handover code as</span><br style="font-size:12.8px"><span style="font-size:12.8px">> well, and have seen some code concerned with sync and async HO.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> You say that you are able to do sync HO but not async. However, it appeared to</span><br style="font-size:12.8px"><span style="font-size:12.8px">> me so far that all we ever do is async HO. i.e., in handover_logic.c, we have</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px"> > rc = rsl_chan_activate_lchan(new_</span><span style="font-size:12.8px">lc<wbr>han, RSL_ACT_INTER_ASYNC, ho->ho_ref);</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> and a patch that is in the pipeline now adds even the possibility to pass _SYNC</span><br style="font-size:12.8px"><span style="font-size:12.8px">> instead of _ASYNC (while we're still going to pass _ASYNC anyway in all cases,</span><br style="font-size:12.8px"><span style="font-size:12.8px">> so far).</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">> So either you have SYNC and ASYNC mixed up or we're misunderstanding each</span><br style="font-size:12.8px"><span style="font-size:12.8px">> other... You are asking about osmocom code, right?</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I am talking about the code from OSMOCOM-BB and there is no file name handover_logic.c.</span></div><div><span style="font-size:12.8px">I think you are talking about code from openBTS. </span></div><div><span style="font-size:12.8px"><br></span></div><div><p class="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">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 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="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">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="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">- 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="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">- 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="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">- Frequency compensation needed to be performed using the afc_correct function before reading the SB.</p><p class="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">* 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="gmail-m_-1055133577450557776gmail-m_6480895723310458030gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">These things, when added to the code did the trick and BSIC of the neighbours was obtained.</p></div><div><span class="gmail-m_-5120605421030621106gmail-im" style="font-size:12.8px"><p class="gmail-m_-5120605421030621106gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="margin-bottom:0in;line-height:12.8px">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></span><p class="gmail-m_-5120605421030621106gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">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. </p><p class="gmail-m_-5120605421030621106gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">Regards</p><p class="gmail-m_-5120605421030621106gmail-m_9167483730509982188m_4683311972448293498gmail-western" style="font-size:12.8px;margin-bottom:0in;line-height:12.8px">M. Awais</p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 15, 2018 at 5:39 PM, Neels Hofmeyr <span dir="ltr"><<a href="mailto:nhofmeyr@sysmocom.de" target="_blank">nhofmeyr@sysmocom.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Muhammad,<br>
<span class=""><br>
On Mon, Jan 15, 2018 at 03:03:10PM +0500, Muhammad Awais Aslam wrote:<br>
> Hi,<br>
><br>
> We have manged to decode the BSIC in dedicated mode which were not<br>
> implemented before.<br>
<br>
</span>Osmocom lives by contribution. If you have implemented useful parts that we<br>
don't support yet, please submit them back to us -- that would be highly<br>
appreciated.<br>
<a href="http://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards#Submitting-Patches" rel="noreferrer" target="_blank">http://osmocom.org/projects/<wbr>cellular-infrastructure/wiki/<wbr>Coding_standards#Submitting-<wbr>Patches</a><br>
<span class=""><br>
> Now we are working on the synchronize and<br>
> non-synchronize Handover. Once we send the fake measurement report to the<br>
> BTS we get a handover command from the network. That could be synchronized<br>
> or non-synchronized.<br>
><br>
> In case of synchronized hand over, without making any changes in the TPU<br>
> clock offset and the frame number and frequency correction, we are able to<br>
> complete the handover process most of the time.<br>
><br>
> In case of non-synchronized handover, a physical info is required from the<br>
> network when mobile station would send Handover access burst to the network<br>
> before the timer expires but we never get physical info during this period.<br>
> Here we are stuck.<br>
<br>
</span>I'm currently working on handover, though my attention is (should be) more on<br>
the HO decision making process: trigger handover due to load considerations.<br>
<br>
In the process though I am touching and testing the stock handover code as<br>
well, and have seen some code concerned with sync and async HO.<br>
<br>
You say that you are able to do sync HO but not async. However, it appeared to<br>
me so far that all we ever do is async HO. i.e., in handover_logic.c, we have<br>
<br>
  rc = rsl_chan_activate_lchan(new_<wbr>lchan, RSL_ACT_INTER_ASYNC, ho->ho_ref);<br>
<br>
and a patch that is in the pipeline now adds even the possibility to pass _SYNC<br>
instead of _ASYNC (while we're still going to pass _ASYNC anyway in all cases,<br>
so far).<br>
<br>
So either you have SYNC and ASYNC mixed up or we're misunderstanding each<br>
other... You are asking about osmocom code, right?<br>
<span class="HOEnZb"><font color="#888888"><br>
~N<br>
<br>
</font></span></blockquote></div><br></div>