[PATCH] doc: Add Location Services API

[PATCH] doc: Add Location Services API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 2868 bytes --]

From: Sjur Brændeland <sjur.brandeland@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 0000000..18ef230
--- /dev/null
+++ b/doc/location-services-api.txt
@@ -0,0 +1,56 @@
+LocationServicesManager hierarchy
+=================================
+
+Service	org.ofono
+Interface	org.ofono.LocationServicesManager
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods	dict 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.
+
+
+Signals	PropertyChanged(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

Re: [PATCH] doc: Add Location Services API

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 4654 bytes --]

Hi Sjur and Simon,

On 11/11/2010 01:44 PM, Sjur Brændeland wrote:
> From: Sjur Brændeland <sjur.brandeland@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 0000000..18ef230
> --- /dev/null
> +++ b/doc/location-services-api.txt
> @@ -0,0 +1,56 @@
> +LocationServicesManager hierarchy
> +=================================
> +
> +Service	org.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,...}
> +
> +Methods	dict 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.
> +
> +
> +Signals	PropertyChanged(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.

How about transforming this signal into an Agent based API instead.  So
let us have a LocationServicesAgent API with the following rough API:

LocationServicesAgent

* Release() - Self explanatory
* HandleRequest(string xml) - Essentially gets passed the data from the
+CPOSR unsolicited response.

We can then add two more methods to the LocationServices interface:

* RegisterAgent()
* UnregisterAgent()

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

This property can then be potentially made redundant.  E.g. if there's
no agent registered, the network position requests are turned off.  Once
the agent is registered, they are turned on.

The SendPositioningControl function can then be tweaked to return an
error if the Agent is not registered.  I assume there's nothing useful
we can do without someone handling the data returned by +CPOSR.

What about other location services related commands defined in 27.007?
How do they fit in? E.g.:
- +CMOLR
- +CMTLR
- +CMTLRA

Regards,
-Denis

Re: [PATCH] doc: Add Location Services API

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 5279 bytes --]

Hi Denis,

> > 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 0000000..18ef230
> > --- /dev/null
> > +++ b/doc/location-services-api.txt
> > @@ -0,0 +1,56 @@
> > +LocationServicesManager hierarchy
> > +=================================
> > +
> > +Service	org.ofono
> > +Interface	org.ofono.LocationServicesManager
> 
> I actually think LocationServices is enough..

sounds good to me.

> 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,...}
> > +
> > +Methods	dict 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.
> > +
> > +
> > +Signals	PropertyChanged(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.
> 
> How about transforming this signal into an Agent based API instead.  So
> let us have a LocationServicesAgent API with the following rough API:
> 
> LocationServicesAgent
> 
> * Release() - Self explanatory
> * HandleRequest(string xml) - Essentially gets passed the data from the
> +CPOSR unsolicited response.
> 
> We can then add two more methods to the LocationServices interface:
> 
> * RegisterAgent()
> * UnregisterAgent()

Sounds simple and straight forward to me. That way we can even tell the
modem clearly if we have an application handling this or not. And in
addition we can track the lifetime of such an application.

> > +
> > +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.
> 
> This property can then be potentially made redundant.  E.g. if there's
> no agent registered, the network position requests are turned off.  Once
> the agent is registered, they are turned on.
> 
> The SendPositioningControl function can then be tweaked to return an
> error if the Agent is not registered.  I assume there's nothing useful
> we can do without someone handling the data returned by +CPOSR.

Since we are tracking the lifetime of an agent, we could just go one
step further and enforce that only the application that registered the
agent can call this method.

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?

Regards

Marcel

Re: [PATCH] doc: Add Location Services API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

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

RE: [PATCH] doc: Add Location Services API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

Hi Denis,

> -----Original Message-----
> From: Denis Kenzior [mailto:denkenz(a)gmail.com]
> Sent: 11 November 2010 21:50
> To: ofono(a)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

RE: [PATCH] doc: Add Location Services API (resending now that I am on ofono mailing list)

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 6916 bytes --]

Hi Denis,

> -----Original Message-----
> From: Denis Kenzior [mailto:denkenz(a)gmail.com]
> Sent: 11 November 2010 21:50
> To: ofono(a)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:denkenz(a)gmail.com]
> Sent: 11 November 2010 21:50
> To: ofono(a)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.brandeland@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 0000000..18ef230
> > --- /dev/null
> > +++ b/doc/location-services-api.txt
> > @@ -0,0 +1,56 @@
> > +LocationServicesManager hierarchy
> > +=================================
> > +
> > +Service	org.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,...}
> > +
> > +Methods	dict 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.
> > +
> > +
> > +Signals	PropertyChanged(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.
> 
> How about transforming this signal into an Agent based API instead.  So
> let us have a LocationServicesAgent API with the following rough API:
> 
> LocationServicesAgent
> 
> * Release() - Self explanatory
> * HandleRequest(string xml) - Essentially gets passed the data from the
> +CPOSR unsolicited response.
> 
> We can then add two more methods to the LocationServices interface:
> 
> * RegisterAgent()
> * UnregisterAgent()
> 
> > +
> > +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.
> 
> This property can then be potentially made redundant.  E.g. if there's
> no agent registered, the network position requests are turned off.
> Once
> the agent is registered, they are turned on.
> 
> The SendPositioningControl function can then be tweaked to return an
> error if the Agent is not registered.  I assume there's nothing useful
> we can do without someone handling the data returned by +CPOSR.
> 
> What about other location services related commands defined in 27.007?
> How do they fit in? E.g.:
> - +CMOLR
> - +CMTLR
> - +CMTLRA
> 
> Regards,
> -Denis

RE: [PATCH] doc: Add Location Services API (resending now that I am on ofono mailing list)

[Joly, Frederic]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

Hi Simon,

-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Simon LETHBRIDGE
Sent: Thursday, November 18, 2010 10:50 AM
To: Denis Kenzior; ofono(a)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:denkenz(a)gmail.com]
> > Sent: 11 November 2010 21:50
> > To: ofono(a)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.

RE: [PATCH] doc: Add Location Services API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

Hi All,

> -----Original Message-----
> From: Denis Kenzior [mailto:denkenz(a)gmail.com]
> Sent: 11 November 2010 21:50
> To: ofono(a)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.GNSS                    used 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

RE: [PATCH] doc: Add Location Services API

[Bastian, Waldo]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

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-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Sjur Brændeland
Sent: Thursday, November 11, 2010 11:45 AM
To: simon.lethbridge(a)stericsson.com; ofono(a)ofono.org
Cc: sjur.brandeland(a)stericsson.com
Subject: [PATCH] doc: Add Location Services API

From: Sjur Brændeland <sjur.brandeland@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 0000000..18ef230
--- /dev/null
+++ b/doc/location-services-api.txt
@@ -0,0 +1,56 @@
+LocationServicesManager hierarchy
+=================================
+
+Service	org.ofono
+Interface	org.ofono.LocationServicesManager
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods	dict 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.
+
+
+Signals	PropertyChanged(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(a)ofono.org
http://lists.ofono.org/listinfo/ofono

RE: [PATCH] doc: Add Location Services API

[Bastian, Waldo]

[-- Attachment #1: Type: text/plain, Size: 460 bytes --]

[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

RE: [PATCH] doc: Add Location Services API

[Marko.Ovaska]

[-- Attachment #1: Type: text/plain, Size: 1811 bytes --]


: -----Original Message-----
: From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On
: Behalf Of ext Bastian, Waldo

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

Hi!

Entering the thread a bit late and partially to wrong thread. My comments will overlap the AGPS thread as well.

The client for the positioning interfaces two sources: OMA SUPL servers and cellular network servers. The SUPL definitions are in OMA TS ULP and AD SUPL specs, for example V1.0 level from openmobilealliance.org.

The SUPL data handling catch is that the SUPL server command and assistance data format refers directly to "TIA-801, RRLP or RRC" defined data transfer protocols. RRLP and RRC frames are ASN.1 BER en/decoded, and there is limited number of location related commands.

The oFono API means that positioning engine and either modem or oFono driver would need to do the XML to ASN.1 conversions. As discussed in AGPS thread. 27.007 position related definition does not mandate XML as such, it defines the parameters in XML DTD.

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.

  Marko

RE: [PATCH] doc: Add Location Services API

[Joly, Frederic]

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Hi Marko,

>-----Original Message-----
>From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)ofono.org] On Behalf Of Marko.Ovaska(a)nokia.com
>Sent: Monday, November 22, 2010 10:01 AM
>To: ofono(a)ofono.org; simon.lethbridge(a)stericsson.com
>Cc: sjur.brandeland(a)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.

RE: [PATCH] doc: Add Location Services API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

Hi Fred,

> -----Original Message-----
> From: Joly, Frederic [mailto:frederic.joly(a)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

RE: [PATCH] doc: Add Location Services API

[Marko.Ovaska]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]



: Behalf Of Marko.Ovaska(a)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

Re: [PATCH] doc: Add Location Services API

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

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 R&D, Maemo Software, Helsinki

RE: [PATCH] doc: Add Location Services API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]



> -----Original Message-----
> From: Bastian, Waldo [mailto:waldo.bastian(a)intel.com]
> Sent: 20 November 2010 02:04
> To: ofono(a)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

Re: [PATCH] doc: Add Location Services API

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

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 R&D, Maemo Software, Helsinki

RE: [PATCH] doc: Add Location Services API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

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

[RFCv2] doc: Assisted Satellite Navigation API and Agent API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]

From: Simon Lethbridge <simon.lethbridge@stericsson.com>

This is our second proposal for the Assisted Satellite Navigation API,
this time including an Agent API. Hopefully most of the review comments
on our last proposal are included here.

As you can see we have changed the name again, this time to
"Assisted Satellite Navigation".

Feedback is appreciated.
---
 doc/assisted-sattelite-navigation.txt |   56 +++++++++++++++++++++++++++++++++
 1 files changed, 56 insertions(+), 0 deletions(-)
 create mode 100755 doc/assisted-sattelite-navigation.txt

diff --git a/doc/assisted-sattelite-navigation.txt b/doc/assisted-sattelite-navigation.txt
new file mode 100755
index 0000000..6c85a7f
--- /dev/null
+++ b/doc/assisted-sattelite-navigation.txt
@@ -0,0 +1,56 @@
+AssistedSatelliteNavigation hierarchy
+=====================================
+
+Service		org.ofono
+Interface	org.ofono.AssistedSatelliteNavigation
+Object path	[variable prefix]/{modem0,modem1,...}
+
+Methods		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.
+
+		void RegisterPositioningRequestAgent(object path)
+
+			Registers an agent which will be called whenever a
+			CPOSR AT response is received. The Agent must respond
+			to requests using SendPositioningControl.
+
+		void UnregisterPositioningRequestAgent(object path)
+
+			Unregisters the agent.
+
+PositioningRequestAgent hierarchy
+==================================
+
+Service		unique name
+Interface	org.ofono.PositioningRequestAgent
+Object path	freely definable
+
+Methods	void 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 method
+			maps directly to the 3GPP defined +CPOSR unsolicited
+			result code.
+
+		void AssistanceDataReset()
+
+			A request has been received from the network that all
+			assistance data should be reset.  This is used for 3gpp
+			performance tests.
+
+		void Release()
+
+			Agent is being released, possibly because of oFono
+			terminating, AssistedSatelliteNavigation interface
+			is being torn down or modem off.
+			No UnregisterAgent call is needed.
-- 
1.6.3.3

Re: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

Hi Sjur,

2010/11/22 Sjur Brændeland <sjurbren@gmail.com>:
> +Methods                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.
...
> +PositioningRequestAgent hierarchy
> +==================================
> +
> +Service                unique name
> +Interface      org.ofono.PositioningRequestAgent
> +Object path    freely definable
> +
> +Methods        void 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 method
> +                       maps directly to the 3GPP defined +CPOSR unsolicited
> +                       result code.

Since (correct me if I'm wrong) SendPositioningControl can only be
called in response to PositioningRequest(), it would seem more logical
to skip SendPositioningControl and have the agent return the xml
string from PositioningRequest(), e.g.

string PositioningRequest(string xml_element)

A D-bus call can take a couple of minutes to respond if needed.

Best regards

RE: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Hi Andrzej

> -----Original Message-----
> From: andrzej zaborowski [mailto:balrogg(a)gmail.com]


> 
> Since (correct me if I'm wrong) SendPositioningControl can only be
> called in response to PositioningRequest(), it would seem more logical
> to skip SendPositioningControl and have the agent return the xml
> string from PositioningRequest(), e.g.
> 
> string PositioningRequest(string xml_element)
> 
> A D-bus call can take a couple of minutes to respond if needed.
> 
There may be several calls to PositioningRequest() before a response is sent.
The ofono agent would need to interpret the messages to see 
whether it should pend waiting for a response from the GNSS/GPS driver.  
Once a positioning procedure has been started it may get aborted.  
This abort may not be detected by the agent If the call
to the PositioningRequest() does not return.

Regards,

Simon

Re: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[andrzej zaborowski]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Hi Simon,

On 23 November 2010 16:07, Simon LETHBRIDGE
<simon.lethbridge@stericsson.com> wrote:
>> -----Original Message-----
>> From: andrzej zaborowski [mailto:balrogg(a)gmail.com]
>> Since (correct me if I'm wrong) SendPositioningControl can only be
>> called in response to PositioningRequest(), it would seem more logical
>> to skip SendPositioningControl and have the agent return the xml
>> string from PositioningRequest(), e.g.
>>
>> string PositioningRequest(string xml_element)
>>
>> A D-bus call can take a couple of minutes to respond if needed.
>>
> There may be several calls to PositioningRequest() before a response is sent.
> The ofono agent would need to interpret the messages to see
> whether it should pend waiting for a response from the GNSS/GPS driver.
> Once a positioning procedure has been started it may get aborted.
> This abort may not be detected by the agent If the call
> to the PositioningRequest() does not return.

So should the agent interface additionally have a method like void
AbortPositioningRequest()?

I have posted this as just a possible idea.  However parallel agent
calls and aborting calls are both used in the agent interfaces in
bluez and ofono.  D-bus is asynchronous, so whether you call a method
and return immediately and then call another method to pass the
response, or make it a single method call is just a difference in the
protocol.

Best regards

RE: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

Hi,

> From: andrzej zaborowski [mailto:balrogg(a)gmail.com]
> Sent: 23 November 2010 17:15
>
> 
> So should the agent interface additionally have a method like void
> AbortPositioningRequest()?
> 
> I have posted this as just a possible idea.  However parallel agent
> calls and aborting calls are both used in the agent interfaces in
> bluez and ofono.  D-bus is asynchronous, so whether you call a method
> and return immediately and then call another method to pass the
> response, or make it a single method call is just a difference in the
> protocol.

The abort is represented as an XML structure in CPOSR so if the 
underlying mechanism is AT commands then this would require ofono to do
some xml parsing.

Regards,

Simon 

Re: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

Hi Sjur & Simon,

> diff --git a/doc/assisted-sattelite-navigation.txt b/doc/assisted-sattelite-navigation.txt
> new file mode 100755
> index 0000000..6c85a7f
> --- /dev/null
> +++ b/doc/assisted-sattelite-navigation.txt
> @@ -0,0 +1,56 @@
> +AssistedSatelliteNavigation hierarchy
> +=====================================

What do you think of naming this AssistedNavigation?  I think the
current name might be a bit too long.

> +
> +Service		org.ofono
> +Interface	org.ofono.AssistedSatelliteNavigation
> +Object path	[variable prefix]/{modem0,modem1,...}
> +
> +Methods		void SendPositioningControl(string xml_element)

What do you think of SendPositioningElement?

> +
> +			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.
> +
> +		void RegisterPositioningRequestAgent(object path)
> +
> +			Registers an agent which will be called whenever a
> +			CPOSR AT response is received. The Agent must respond
> +			to requests using SendPositioningControl.
> +
> +		void UnregisterPositioningRequestAgent(object path)
> +
> +			Unregisters the agent.
> +
> +PositioningRequestAgent hierarchy
> +==================================
> +
> +Service		unique name
> +Interface	org.ofono.PositioningRequestAgent
> +Object path	freely definable
> +
> +Methods	void PositioningRequest(string xml_element)

I think that 'Request' will be sufficient.  Positioning is already part
of the agent name.

> +
> +			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 method
> +			maps directly to the 3GPP defined +CPOSR unsolicited
> +			result code.
> +
> +		void AssistanceDataReset()

I suggest ResetAssistanceData here.

> +
> +			A request has been received from the network that all
> +			assistance data should be reset.  This is used for 3gpp
> +			performance tests.
> +
> +		void Release()
> +
> +			Agent is being released, possibly because of oFono
> +			terminating, AssistedSatelliteNavigation interface
> +			is being torn down or modem off.
> +			No UnregisterAgent call is needed.

The only other change I'd make is to mark the entire interface
'experimental', but I can take care of that as well.

Otherwise the proposal looks good to me.

Regards,
-Denis

RE: [RFCv2] doc: Assisted Satellite Navigation API and Agent API

[Simon LETHBRIDGE]

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

Hi Denis

Sorry that it has taken so long for me to reply.

> > +AssistedSatelliteNavigation hierarchy
> > +=====================================
> 
> What do you think of naming this AssistedNavigation?  I think the
> current name might be a bit too long.
> 
That is a possibility.  The terminology used in the 3GGP specs is Global Satellite Navigation System (GNSS) for the technology.  The terms "Position Measurement Procedure" and "Assistance Data Delivery Procedure" are used in RRLP, for the procedures. I have some concern
that it may be difficult to relate the oFono terminology to that used in the 3GPP standards.

There are other positioning technologies such as EOTD and OTDOA that are not satellite based, although hopefully it would be obvious that these would be handled entirely in the modem.

My preference for a short name would be GNSS, since this term is used extensively in the 3gpp recommendations, although it has the disadvantage of being an abbreviation. If "Assisted Satellite Navigation" is too long then I suppose "Global Satellite Navigation System" would be too long too.

Generic terms like "Positioning" would be problematic since the supplementary service positioning procedures like MOLR (Mobile Originated Location Request) are not covered by this API.

Regards,

Simon