Dear Neels,

Thanks for the response.

Osmocom lives by contribution. If you have implemented useful parts that

we

don't support yet, please submit them back to us -- that would be highly appreciated. http://osmocom.org/projects/cellular-infrastructure/wiki/C

oding_standards#Submitting-Patches

I have already uploaded the code which could be find here:

https://gerrit.osmocom.org/5490

I'm currently working on handover, though my attention is (should be)

more on

the HO decision making process: trigger handover due to load

considerations.

In the process though I am touching and testing the stock handover code as well, and have seen some code concerned with sync and async HO.

You say that you are able to do sync HO but not async. However, it

appeared to

me so far that all we ever do is async HO. i.e., in handover_logic.c, we

have

rc = rsl_chan_activate_lchan(new_lchan, RSL_ACT_INTER_ASYNC, ho->ho_ref);

and a patch that is in the pipeline now adds even the possibility to pass

_SYNC

instead of _ASYNC (while we're still going to pass _ASYNC anyway in all

cases,

so far).

So either you have SYNC and ASYNC mixed up or we're misunderstanding each other... You are asking about osmocom code, right?

I am talking about the code from OSMOCOM-BB and there is no file name handover_logic.c. I think you are talking about code from openBTS.

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.

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:

- 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.

- 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).

- Frequency compensation needed to be performed using the afc_correct function before reading the SB.

* 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.

These things, when added to the code did the trick and BSIC of the neighbours was obtained.

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.

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.

Regards

M. Awais

On Mon, Jan 15, 2018 at 5:39 PM, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:

Hi Muhammad,

On Mon, Jan 15, 2018 at 03:03:10PM +0500, Muhammad Awais Aslam wrote:

...

Hi,

We have manged to decode the BSIC in dedicated mode which were not implemented before.

Osmocom lives by contribution. If you have implemented useful parts that we don't support yet, please submit them back to us -- that would be highly appreciated. http://osmocom.org/projects/cellular-infrastructure/wiki/ Coding_standards#Submitting-Patches

...

Now we are working on the synchronize and non-synchronize Handover. Once we send the fake measurement report to the BTS we get a handover command from the network. That could be

synchronized

...

or non-synchronized.

In case of synchronized hand over, without making any changes in the TPU clock offset and the frame number and frequency correction, we are able

to

...

complete the handover process most of the time.

In case of non-synchronized handover, a physical info is required from

the

...

network when mobile station would send Handover access burst to the

network

...

before the timer expires but we never get physical info during this

period.

...

Here we are stuck.

I'm currently working on handover, though my attention is (should be) more on the HO decision making process: trigger handover due to load considerations.

In the process though I am touching and testing the stock handover code as well, and have seen some code concerned with sync and async HO.

You say that you are able to do sync HO but not async. However, it appeared to me so far that all we ever do is async HO. i.e., in handover_logic.c, we have

rc = rsl_chan_activate_lchan(new_lchan, RSL_ACT_INTER_ASYNC, ho->ho_ref);

and a patch that is in the pipeline now adds even the possibility to pass _SYNC instead of _ASYNC (while we're still going to pass _ASYNC anyway in all cases, so far).

So either you have SYNC and ASYNC mixed up or we're misunderstanding each other... You are asking about osmocom code, right?

~N

...and let me add that osmocom-bb would better be discussed in the baseband-devel@ mailing list, since mails to openbsc@ are expected to be about the core network / BSS part of Osmocom.

~N

I've already responded to Muhammad off-list, but I feel that everyone else should be aware of it too: if anyone needs to know how a GSM MS should implement handover or any other of the myriad features not supported by OsmocomBB, you should study the official GSM MS firmware source code from some mainstream reputable GSM MS chipset+firmware vendor such as FreeCalypso (former TI), MediaTek or Qualcomm, and see how they do it.

I don't know whether or not one can get the official firmware source from Qualcomm or MTK (not my personal area of interest - after all, they are my competitors), but the complete source code for the official GSM MS firmware from TI (which most certainly has working handovers of all types - I've been able to stay on a call without dropping while driving between San Diego and Los Angeles, using a TI-based phone) can be found here:

https://bitbucket.org/falconian/fc-magnetite

Or to be more pedantic, it is not the raw code salvage from TI (what TI threw in the trash as they exited the baseband chipset business), but rather my own actively maintained version thereof. The original code from TI ran only on their own development boards, the ones with weird names like D-Sample and I-Sample; I have one of those original D-Sample boards, but the board I have is likely the world's last remaining one, hence I have ported the firmware to run on more practically available hardware - it can now run on the same Mot C1xx phones that are targeted by OsmocomBB, and I also have my own GSM MS development board (FCDEV3B) which I have designed and built specifically for the purpose of running this firmware.

All of you are more than welcome to study this fully working firmware and see how it implements handovers or whatever other feature you may be interested in, and because you can also run this fw on practically available hardware and see it working, you are not limited to just staring at the code - you can see its debug trace output as it runs, you can examine the state of various internal variables as it does the handovers and other operations, you can add extra debug traces of your own to print out whatever you are interested in, and so forth - that's the power of having a fully functional commercial product quality GSM MS implementation available in full source form, running on practically available hw.

M~