Location retrieval - Allow additional area types in the response

[JoachimDahlgren]

Problem description In the current version of the location retrieval API when responding the location of a device, we always do this in form of a circle. However when requesting the location from a southbound system such as NEF/SCEF or GMLC it is common to receive a non-circular area. When transforming such non-circular area to a circle we will lose accuracy.

Possible evolution Allow non-circular areas in the response. That would enable the location retrieval API to return what has been received from southbound systems without transformation. Thereby the accuracy will be kept.

Additional context 3GPP specifies the following geographical areas:

• Point
• PointUncertaintyCircle
• PointUncertaintyEllipse
• Polygon
• PointAltitude
• PointAltitudeUncertainty
• EllipsoidArc

[jlurien]

Thanks @JoachimDahlgren. After some internal feedback from our network team, I think that it is a good idea to consider geometries other than Circle for location-retrieval API. Polygon is the most obvious. We may consider as well Ellipse and EllipsoidArc. Regarding the ones that include altitude, we need further research about the degree of support for this in networks. Do you have any additional input regarding the support for altitude in current networks?

[alpaycetin74]

As far as I know, VF Italy has an eSMLC and it can return an Ellipse with altitude.

[jlurien]

3GPP TS 29.572 provides an OAS version with the geometries listed by @JoachimDahlgren. Indeed the approach it is very similar to or polymorphic Area, so it would be very easy to map.

For polygons, they are defined as a list of 3 to 15 (lat, long) points. Only doubt here is whether the maximum to 15 points should be kept in our API.

Ellipses are similar to circles but with 2 values for semi major and semi minor axes, and other for orientation in degrees. We can added it if demanded.

For altitude, let's see if we have relevant use cases.

[jlurien]

As far as I know, VF Italy has an eSMLC and it can return an Ellipse with altitude.

Is this being returned in practice or is it theoretical? Altitude for a "flying" object above ground level, or is it the altitude of ground level, for example as known from maps?

[alpaycetin74]

I was working with VF Italy about 2 years back when I was in my previous team, and they were deploying the eSMLC for the first time. They were really returning the altitude. I think eSMLC calculated the height of the phone based on the heights of the antennas which it used to triangulate the phone. This was meant to locate emergency callers, so the height was useful information to them.

[bigludo7]

@JoachimDahlgren @jlurien @alpaycetin74 I pushed a first PR to tackle this. I have 2 comments:

• Are we happy to have this enhancement in version v0.1-wip ?
• From API customer perspective, the customer doesn't know if a circle or a polygon will be responded. Not sure this is an issue but need to be considered in particular if we extend this list of area.

We could discuss this in our next meeting.

[jlurien]

My assumption is that client has to be prepared to get any of them. As a feature we could think on an input parameter indicating the area preference in the response, but that would require implementations to make conversions

[alpaycetin74]

The API implementer could modify the returned shape only to decrease the granularity. For instance, the client may require a circle (because it is simple). The network may return an arc. API implementer could draw a circle that contains this arc, but it would create a more "pessimistic" response. The API implementer cannot create a shape the contains a more accurate location than what the network can provide, only for the purpose of matching the client's preference.