RE: [PATCH] doc: Add Location Services API
Hi Denis, -Original Message- From: Denis Kenzior [mailto:denk...@gmail.com] Sent: 11 November 2010 21:50 To: ofono@ofono.org Cc: Sjur Brændeland; Simon LETHBRIDGE; Sjur BRENDELAND Subject: Re: [PATCH] doc: Add Location Services API So let me summarize 27.007 briefly. It defines the following elements for +CPOS/+CPOSR: - location - assist_data - pos_meas - GPS_meas - GPS_assist_req - msg - pos_err So from my understanding +CPOS command can be used to send location, GPS_assist_req and pos_err elements. And +CPOSR can transfer the following elements from the network: assist_data, pos_meas, msg. Am I right so far? This is substantially correct, however the assistance data request can only be made in response to a positioning request from the network. If assistance is required otherwise then an MOLR is needed, which we don't support yet. Where does the GPS_meas element fall into? There are two types of procedure MSB where the location is calculated in the mobile, and MSA where it is calculated in the network. For MSA code phase measurements and doppler are sent to the network. One possible benefit of MSA procedures is that less assistance data needs to be transferred. What about other location services related commands defined in 27.007? How do they fit in? E.g.: - +CMOLR - +CMTLR - +CMTLRA These are not required for NILR (Network Initiated - Location Requests) procedures (e.g. E911 procedures). However it could be useful to add support later. The current proposal only supports NILR. Regards, Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
Hi Rémi, Would it make sense to add a ResetStoredInfo signal to the DBUS API for implementation in a modem specific way? Yes. There are no standard commands for that and it is very much needed for conformance testing. However, I would have thought that this was an issue between the automatic test equipment and the (Linux) positioning engine. In this case, what business does oFono and the modem have there? The assistance data reset command is received via control plane signalling for the 3GPP performance tests. Regards, Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
: Behalf Of marko.ova...@nokia.com : Sent: Monday, November 22, 2010 10:01 AM -- : I'm proposing that either we have : a) fully opaque 'raw' 3GPP defined frames between modem and Linux : b) or well defined D-BUS API for LCS commands, but keeping the : assistance payload in 'raw' format Checked the 27.007 and Sjur's proposal: XML format after, for example +CPOS command, is above a) option with XML formatted payload. I'll rephrase the ASN.1 formatted opaque option as a2). Rationale is that position engine in Linux user space or GPS chip must do ASN.1 processing in handset: Positioning engine uses both OMA specified SUPL server and LCS server in cellular network. Adding new format to cellular network LCS server messages increases work into modem and positioning engine. Then the ASN.1 formatted interface void SendPositioningControl(string xml_element) becomes void SendPositioningControl(string asn1_element) and text refers to RRLP format in TS 44.031 and RRC in TS 25.331. : For the option b, I would tend to not support you. I just recheck the : 23.032 (Universal GeoGraphical Area Description), and the number of : ways to express a position with velocity and uncertainty may not make : the API simple. : Just have a look for instance the +CMOLR's XML DTD location_parameters. : :) Payload gets complicated, I agree. Following the generic oFono interface definitions... Marko ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add Location Services API
On Saturday 20 November 2010 03:01:03 ext Bastian, Waldo, you wrote: Conformance testing per 3GPP 34.109s5.4.1.3 requires that RESET UE POSITIONING STORED INFO is handled. Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12. As far as I can see there is no provision for that in commands / XML defined by 27.007. Would it make sense to add a ResetStoredInfo signal to the DBUS API for implementation in a modem specific way? Yes. There are no standard commands for that and it is very much needed for conformance testing. However, I would have thought that this was an issue between the automatic test equipment and the (Linux) positioning engine. In this case, what business does oFono and the modem have there? Do some modems also cache some GPS- related data? -- Rémi Denis-Courmont Nokia Devices RD, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add Location Services API
On Tuesday 23 November 2010 01:16:00 ext Joly, Frederic, you wrote: I just recheck the 23.032 (Universal GeoGraphical Area Description), and the number of ways to express a position with velocity and uncertainty may not make the API simple. Just have a look for instance the +CMOLR's XML DTD location_parameters. :) Moreover, GPS vendors and other positioning professionals would find more logical to propose to use the WGS 84 datum for instance which is widely used and leave the burden to map the position to 3GPP style... I am afraid with enough time and products, we will find all possible combinations: - modems that only talk 27.007 XML, - modems that only talk raw binary, - modems that support both, - hopeless modems that do none. Furthermore, the data flow can go in both directions: AT+CPOS is engine-oFono-modem, AT+CPOSR is modem-oFono-engine. I would think that oFono needs to hide the differences between modems, which mean it will need to convert in some cases. Thus oFono would need to be able to convert both ways in any case, right? This is going to be painful. The alternative consists of providing a *leaky* abstraction where oFono only returns and accepts the format(s) that the modem understands. With that in mind, I tend to agree that binary seems like a nicer abstraction for the positioning engine to use than XML. But if oFono has to implement conversion in both direction, it might be that we can provide both formats over D-Bus? -- Rémi Denis-Courmont Nokia Devices RD, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
Hi Fred, -Original Message- From: Joly, Frederic [mailto:frederic.j...@intel.com] For the option b, I would tend to not support you. I just recheck the 23.032 (Universal GeoGraphical Area Description), and the number of ways to express a position with velocity and uncertainty may not make the API simple. Just have a look for instance the +CMOLR's XML DTD location_parameters. :) Moreover, GPS vendors and other positioning professionals would find more logical to propose to use the WGS 84 datum for instance which is widely used and leave the burden to map the position to 3GPP style... With respect to the GAD shape in practise Ellipsoid point with altitude and uncertainty ellipsoid is used. The shapes Polygon and Ellipsoid Arc are not used and the other shapes are a subset of Ellipsoid point with altitude and uncertainty ellipsoid. Regards, Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
-Original Message- From: Bastian, Waldo [mailto:waldo.bast...@intel.com] Sent: 20 November 2010 02:04 To: ofono@ofono.org; Simon LETHBRIDGE Cc: Sjur BRENDELAND Subject: RE: [PATCH] doc: Add Location Services API Conformance testing per 3GPP 34.109s5.4.1.3 requires that RESET UE POSITIONING STORED INFO is handled. Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12. As far as I can see there is no provision for that in commands / XML defined by 27.007. Would it make sense to add a ResetStoredInfo signal to the DBUS API for implementation in a modem specific way? You are correct, this will need to be added to the API. Regards, Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API (resending now that I am on ofono mailing list)
Hi Simon, -Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Simon LETHBRIDGE Sent: Thursday, November 18, 2010 10:50 AM To: Denis Kenzior; ofono@ofono.org Cc: Sjur BRENDELAND Subject: RE: [PATCH] doc: Add Location Services API (resending now that I am on ofono mailing list) Hi Denis, -Original Message- From: Denis Kenzior [mailto:denk...@gmail.com] Sent: 11 November 2010 21:50 To: ofono@ofono.org Cc: Sjur Brændeland; Simon LETHBRIDGE; Sjur BRENDELAND Subject: Re: [PATCH] doc: Add Location Services API And +CPOSR can transfer the following elements from the network: assist_data, pos_meas, msg. Am I right so far? This is substantially correct, however the assistance data request can only be made in response to a positioning request from the network. If assistance is required otherwise then an MOLR is needed, which we don't support yet. Since you mentioned in another post the LPP, I would just point out that in 2G and 3G the MO-LR invoke was needed to request the assistance data, but for 4G, this is not anymore the case. It seems you can directly request the assistance data at the access stratum level. (see 36.355 §5.2.1 §6.3). So we should consider also assistance data request in the API proposal, I believe. BR, Fred - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
Hi Marko, -Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of marko.ova...@nokia.com Sent: Monday, November 22, 2010 10:01 AM To: ofono@ofono.org; simon.lethbri...@stericsson.com Cc: sjur.brandel...@stericsson.com Subject: RE: [PATCH] doc: Add Location Services API I'm proposing that either we have a) fully opaque 'raw' 3GPP defined frames between modem and Linux b) or well defined D-BUS API for LCS commands, but keeping the assistance payload in 'raw' format Both a) and b) approaches break the 27.007 defined positioning commands. Rationale is that 27.007 positioning related re-formatting creates additional effort to any positioning engine, whether it resides in modem, dedicated chip or in Linux. For the option b, I would tend to not support you. I just recheck the 23.032 (Universal GeoGraphical Area Description), and the number of ways to express a position with velocity and uncertainty may not make the API simple. Just have a look for instance the +CMOLR's XML DTD location_parameters. :) Moreover, GPS vendors and other positioning professionals would find more logical to propose to use the WGS 84 datum for instance which is widely used and leave the burden to map the position to 3GPP style... BR, Fred - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
Conformance testing per 3GPP 34.109s5.4.1.3 requires that
RESET UE POSITIONING STORED INFO is handled.
Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12.
As far as I can see there is no provision for that in commands / XML
defined by 27.007.
Would it make sense to add a ResetStoredInfo signal to the DBUS API for
implementation in a modem specific way?
Cheers,
Waldo
-Original Message-
From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of
Sjur Brændeland
Sent: Thursday, November 11, 2010 11:45 AM
To: simon.lethbri...@stericsson.com; ofono@ofono.org
Cc: sjur.brandel...@stericsson.com
Subject: [PATCH] doc: Add Location Services API
From: Sjur Brændeland sjur.brandel...@stericsson.com
As requested, this is our initial proposal for a minimal API
in order to support E911, based on the 27.007 defined AT
commands.
We've discussed internally different names for this API:
AGNSSManager or AssistedGlobalNavigationSatelliteSystem,
but ended up with the simpler LocationServicesManager.
Looking forward to your comments on this API.
Regards,
Simon Lethbridge and
Sjur Brændeland
---
doc/location-services-api.txt | 56 +
1 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 doc/location-services-api.txt
diff --git a/doc/location-services-api.txt b/doc/location-services-api.txt
new file mode 100644
index 000..18ef230
--- /dev/null
+++ b/doc/location-services-api.txt
@@ -0,0 +1,56 @@
+LocationServicesManager hierarchy
+=
+
+Serviceorg.ofono
+Interface org.ofono.LocationServicesManager
+Object path[variable prefix]/{modem0,modem1,...}
+
+Methodsdict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.DoesNotExist
+
+ void SendPositioningControl(string xml_element)
+
+ Send an XML element conforming to the XML DTD for pos
+ as defined in 3GPP 27.007 Table 8.55-2. This xml is
+ used for transferring data associated with positioning
+ requests received via control plane from the network.
+ This includes assistance data requests and the results
+ of positioning procedures. This method maps directly to
+ the 3GPP 27.007 AT+CPOS command.
+
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ PositioningRequest(string xml_element)
+
+ Receive an XML element conforming to the XML DTD for
+ pos in 3GPP 27.007. This xml is used for transferring
+ data associated with positioning requests received, via
+ control plane, from the network. This includes
+ measurement requests and assistance data. This signal
+ maps directly to the 3GPP defined +CPOSR unsolicited
+ result code.
+
+Properties boolean NetworkInitiatedProceduresEnabled [readwrite]
+
+ If NetworkInitiatedProceduresEnabled is False, then
+ no Position Requests from the network are accepted.
+ The modem is not enabled for positioning requests
+ from the networks view point.
--
1.6.3.3
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API
[Resend without the bottom quote - Damn you Outlook] Conformance testing per 3GPP 34.109s5.4.1.3 requires that RESET UE POSITIONING STORED INFO is handled. Similar for 3GPP RESET MS POSITIONING STORED INFO per 3GPP 44.014s12. As far as I can see there is no provision for that in commands / XML defined by 27.007. Would it make sense to add a ResetStoredInfo signal to the DBUS API for implementation in a modem specific way? Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [PATCH] doc: Add Location Services API (resending now that I am on ofono mailing list)
Hi Denis,
-Original Message-
From: Denis Kenzior [mailto:denk...@gmail.com]
Sent: 11 November 2010 21:50
To: ofono@ofono.org
Cc: Sjur Brændeland; Simon LETHBRIDGE; Sjur BRENDELAND
Subject: Re: [PATCH] doc: Add Location Services API
So let me summarize 27.007 briefly. It defines the following elements
for +CPOS/+CPOSR:
- location
- assist_data
- pos_meas
- GPS_meas
- GPS_assist_req
- msg
- pos_err
So from my understanding +CPOS command can be used to send location,
GPS_assist_req and pos_err elements.
And +CPOSR can transfer the following elements from the network:
assist_data, pos_meas, msg.
Am I right so far?
This is substantially correct, however the assistance data request can only be
made in response to a positioning request from the network. If assistance is
required otherwise then an MOLR is needed, which we don't support yet.
Where does the GPS_meas element fall into?
There are two types of procedure MSB where the location is calculated in the
mobile, and MSA where it is calculated in the network. For MSA code phase
measurements and doppler are sent to the network. One possible benefit of MSA
procedures is that less assistance data needs to be transferred.
What about other location services related commands defined in 27.007?
How do they fit in? E.g.:
- +CMOLR
- +CMTLR
- +CMTLRA
These are not required for NILR (Network Initiated - Location Requests)
procedures (e.g. E911 procedures). However it could be useful to add support
later.
The current proposal only supports NILR.
Regards,
Simon
-Original Message-
From: Denis Kenzior [mailto:denk...@gmail.com]
Sent: 11 November 2010 21:50
To: ofono@ofono.org
Cc: Sjur Brændeland; Simon LETHBRIDGE; Sjur BRENDELAND
Subject: Re: [PATCH] doc: Add Location Services API
Hi Sjur and Simon,
On 11/11/2010 01:44 PM, Sjur Brændeland wrote:
From: Sjur Brændeland sjur.brandel...@stericsson.com
As requested, this is our initial proposal for a minimal API
in order to support E911, based on the 27.007 defined AT
commands.
We've discussed internally different names for this API:
AGNSSManager or AssistedGlobalNavigationSatelliteSystem,
but ended up with the simpler LocationServicesManager.
Looking forward to your comments on this API.
Regards,
Simon Lethbridge and
Sjur Brændeland
---
doc/location-services-api.txt | 56
+
1 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 doc/location-services-api.txt
diff --git a/doc/location-services-api.txt b/doc/location-services-
api.txt
new file mode 100644
index 000..18ef230
--- /dev/null
+++ b/doc/location-services-api.txt
@@ -0,0 +1,56 @@
+LocationServicesManager hierarchy
+=
+
+Serviceorg.ofono
+Interface org.ofono.LocationServicesManager
I actually think LocationServices is enough..
So let me summarize 27.007 briefly. It defines the following elements
for +CPOS/+CPOSR:
- location
- assist_data
- pos_meas
- GPS_meas
- GPS_assist_req
- msg
- pos_err
So from my understanding +CPOS command can be used to send location,
GPS_assist_req and pos_err elements.
And +CPOSR can transfer the following elements from the network:
assist_data, pos_meas, msg.
Am I right so far?
Where does the GPS_meas element fall into?
+Object path[variable prefix]/{modem0,modem1,...}
+
+Methodsdict GetProperties()
+
+ Returns properties for the modem object. See
+ the properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed as read-write are
+ changeable. On success a PropertyChanged signal
+ will be emitted.
+
+ Possible Errors: [service].Error.InvalidArguments
+[service].Error.DoesNotExist
I think we can get rid of the above two methods, see below...
+
+ void SendPositioningControl(string xml_element)
+
+ Send an XML element conforming to the XML DTD for
pos
+ as defined in 3GPP 27.007 Table 8.55-2. This xml is
+ used for transferring data associated with
positioning
+ requests received via control plane from the network.
+ This includes assistance data requests and the
results
+ of positioning procedures. This method maps directly
to
+ the 3GPP 27.007 AT+CPOS command.
+
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value
RE: [PATCH] doc: Add Location Services API
Hi All, -Original Message- From: Denis Kenzior [mailto:denk...@gmail.com] Sent: 11 November 2010 21:50 To: ofono@ofono.org Cc: Sjur Brændeland; Simon LETHBRIDGE; Sjur BRENDELAND Subject: Re: [PATCH] doc: Add Location Services API What about other location services related commands defined in 27.007? How do they fit in? E.g.: - +CMOLR - +CMTLR - +CMTLRA The proposed API only covers support for Measure Position Requests from the network. This is sufficient for E911 (and other NILRs network initiated - location requests ) Measure Position Requests use the RRLP, RRC and LPP 3GPP protocols. It does not support MTLR (Mobile Terminated - Location Requests ), this is where the user is notified that a 3rd party is trying to find the users location. MTLRs use the 3GPP SS protocol. The proposal does not support MOLR (Mobile Originated - Positioning Requests) where the user requests the users position. MOLR's can be used to request assistance data using a different protocol to that used with Measure Position Requests. MOLRs also use the 3GPP SS protocol. We have had some discussion about this internally. It would be beneficial to define the APIs in a way that keeps Measure Position Requests separate from MOLRs and MTLRs. There are three possible approaches 1 Define different top level interfaces e.g. org.ofono.LocationServicesManager used by applications and org.ofono.GNSSused by the GNSS/GPS driver 2 Define different agents e.g. RegisterPositioningRequestAgent used by the GNSS driver RegisterPositioningNotificationAgent used for MTLR notifications RegisterLocationAgent used for applications 3 Use one set of interfaces for everything. Which approached is preferred? For mobile originated procedures the SS protocol must be used to get locations and/or assistance data. for network initiated procedures on ly the RRLP, RRC or LPP protocols can be used. Regards, Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH] doc: Add Location Services API
Hi Marcel. So far this looks like a nice and simple proposal. And it is driven by an existing standard. I like that. Sjur, are you guys up to the task of sending an initial atom implementation and atmodem driver for it? Yes, I think we should be able to, as longs as there is no big hurry. I'll send a patch on the TODO shortly. Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
