GCI search & multiple cell location

[barbiz]

Hello,

since location accuracy is not enough for us with single cell, we are trying to use multiple cell location.

We tries with %NCELLMEAS = 2 but we don't get multiple cells. Maybe the serving cell has good signal?

Then we tried with GCI search and fw 1.3.4.

%NCELLMEAS = 3,3

and we got those 3 cells (I added newlines for easiness of reading):

%NCELLMEAS: 0,

"0AAE62A2","22201","92B9",65535,0,6254,243,62,19,178936,0,0,

"0319AFA2","22201","92B8",65535,0,6254,295,62,18,178936,0,0,

"0094586F","22210","69D9",65535,0,6354,105,77,29,178973,0,0

so we tried to inject this data into the nrfCloud API:

{
  "lte": [
    {
      "mcc": 222,
      "mnc": 1,
      "eci": 179200674,
      "tac": 37561,
      "earfcn": 6254,
      "adv": 65535,
      "rsrp": -78,
      "rsrq": -10,
      "nmr": [
        {
          "earfcn": 6254,
          "pci": 295,
          "eci": 52015010,
          "rsrp": -78,
          "rsrq": -10.5
        },{
          "earfcn": 6354,
          "pci": 105,
          "eci": 9721967,
          "rsrp": -63,
          "rsrq": -5
        }
      ]
    }
  ]
}

and this is the response:

{
	"lat": 45.39999247,
	"lon": 11.90999508,
	"uncertainty": 2472,
	"fulfilledWith": "MCELL"
}

which does not give any improvement on the original location with SCELL.

Can you help us? Are we formatting the data the wrong way?

Marco

[Cole Hafner]

Hi Marco,

Your formatting is correct. What is the device ID? I can look into the logs and see if I can help you get a better result. 

Thanks,

Cole

[barbiz]

Actually, I am directly calling the API cloud-to-cloud so there is no device id. How can I make my call trackable?

Also, I was wondering: what is the difference between my formatting and passing an array of cells direcly in the "lte" object?

[Cole Hafner]

Hi Marco,

This is very odd indeed. I am passing your findings onto our vendors and will get back to you.

Cole

[barbiz]

Hi Cole,

did you get any news from the vendors?

thanks

Marco

[amessner]

Hi everyone,

We actually ran into the exact same issue.

We use Soracom in Alberta, Canada and when using the GCI search types and mfw_v1.3.4 we do get additional cells as expected. However, when injecting these additional cells into the "nmr" section of the a location request to the nRF Cloud we don't see any improvement on the location either.

Currently we are only evaluating the recent improvements on multicell, so we send the requests directly from the device using a service key.

Thanks
Alex

[Cole Hafner]

Hi Alex and Marco,

Multi cell accuracy depends on a variety of factors: cell density of the area (rural or urban), which cells the SIM carrier is allowed to connect to (irrelevant in 1.3.4), signal strength etc. Sometimes single cell accuracy is just as good, in other cases multi cell is better.

The "uncertainty" response is an estimate of where your device may be relative to the location of the tower, here are some docs. We are working on docs that better explain the details of this.

Alex, will you pass me your device details in a private message? I would like to investigate your specific use case. 

Best Regards,

Cole

[barbiz]

Dear Cole,

I understand, but I honestly think this is an oversimplified explanation.

The cases I am spotting out are very simple: the radio finds three cells, I can spot them on cellmapper and draw the best intersection and provide, manually, a better location than the single cell would allow.

I could do this, theoretically, by a script querying the cloud N times and then making the average.

My question is: why the locations services does not do that? Is there any reason? Or is there any plan to do that?

Or maybe I am wrong: can you please spot out an example where the cloud is actually providing better accuracy with GCI search? (not normal search, we already know that 99% of the cases normal search does not give any further cells)

This would help us to understand how the thing works.

Thanks

Marco

[AndrewKostka]

Hi, Marco: I'm Andrew, I work on the Location Services feature with Cole.
I'd like to offer some more context to the conversation surrounding LTE positioning. First, I think there seems to be a misunderstanding about the term "cell". The term "cell" refers to a specific geographic area that is served by a specific tower, or eNodeB in LTE terminology. Let's look at an example using your original serving tower to see how multicell can improve a position estimate.

Let's take the following request and look at its corresponding cell on CellMapper:

{
 	"lte": [
		{
			"mcc": 222,
			"mnc": 1,
			"tac": 17211,
			"eci": 179200573
		}
	]
}

Finding the corresponding cell on CellMapper means deriving the eNodeB, or tower, ID from the Cell ID. The eNodeB ID here is '700002', and the Sector (or cell) ID is '61'. This is what that cell looks like:

The result we get from nRF Cloud for that data is here:

{
	"lat": 45.4181242,
	"lon": 11.9116044,
	"uncertainty": 796
}

Which correlates to this position:

Now, let's add another nearby cell. Adding another cell from the same eNodeB makes our request:

{
 	"lte": [
		{
			"mcc": 222,
			"mnc": 1,
			"tac": 17211,
			"eci": 179200573
		},
		{
			"mcc": 222,
			"mnc": 1,
			"eci": 179200575,
			"tac": 17211
		}
	]
}

Here's our new cell in CellMapper:

We can see that while this cell has the same serving tower, it is geographically located further to the southwest than our first cell. So, how does this change our results?

{
	"lat": 45.40624738,
	"lon": 11.8985796,
	"uncertainty": 568
}

We can see our new position is over a kilometer further to the southwest, which makes sense given the geographic location of the cells. Additionally, our uncertainty has reduced by about 230M, suggesting we are more confident about the result position.

Unfortunately I wasn't able to find information about the specific cells in your original request on CellMapper, so I can't confirm the location of the actual cells.

[barbiz]

Dear Andrew,

first of all, thank you for your detailed explanation!!

I am having too issues in finding my cells in cellmapper. Thay are in the same eNodeb as your example, but in different sectors which are not in the cellmapper database. however, this is what the radio returns.

On other hand, I am unable to reproduce your results with nrfCloud.

For example, this query:

{
 	"lte": [
		{
			"mcc": 222,
			"mnc": 1,
			"tac": 17211,
			"eci": 179200573
		}
	]
}

returns a different result:

{
	"lat": 45.4146033,
	"lon": 11.9093139,
	"uncertainty": 1201.109,
	"fulfilledWith": "SCELL"
}

Also the second query:

{
 	"lte": [
		{
			"mcc": 222,
			"mnc": 1,
			"tac": 17211,
			"eci": 179200573
		},
		{
			"mcc": 222,
			"mnc": 1,
			"eci": 179200575,
			"tac": 17211
		}
	]
}

does not give any accuracy improvement:

{
	"lat": 45.4146033,
	"lon": 11.9093139,
	"uncertainty": 1201.109,
	"fulfilledWith": "MCELL"
}

Can you help me understand why I am getting different results by calling the API?

thanks much,

Marco

[AndrewKostka]

Hi Marco:

I now see the same result that you do for that data. It is to be expected that results will sometimes change slightly over time, as data sources get refreshed and updated. However, I'm also seeing what you are seeing, that the second cell no longer changes the accuracy. I'm going to look into this in our data sources to gather more information.

[barbiz]

Hello,

yes I understand that data can change but this seems really a suspicious concidence. Consider I never got improvement by adding multiple cells in this way.

Waiting for updates

Marco

[AndrewKostka]

Hi, Marco: I've looked more into why my initial results were different from what I see now on nrfcloud. We have multiple data sources for some areas, and we continuously do performance evaluation in order to rank those data sources. The environment where I did my initial test had slightly outdated rankings. While these rankings in general improve our success rate, in very specific cases like this it can decrease accuracy.

This edge case has given our team some ideas for improvement of this ranking procedure, including checking SCELL vs. MCELL results for uncertainty decreases. I'm sorry if this isn't the answer you were hoping for, but these cases help us improve our service over time.