RE: [RFC] AGPS support
Thanks, Waldo.
I would suggest to add the Radio Access Technology (RAT) indication in the
RequestFineTimeInjection .
It is possible that after the reception of the Assistance Data message from the
network and the request for time injection from the GPS manager that the
radio conditions have forced the modem to change of RAT.
So if the RAT is indicated, OFONO implementation will not have to care about an
eventual change of RAT for the time injection. This will be only handled by the
modem.
BR,
Fred
-Original Message-
From: Bastian, Waldo
Sent: Saturday, May 15, 2010 1:56 AM
To: ofono@ofono.org
Cc: Joly, Frederic
Subject: [RFC] AGPS support
Please find attached a proposal for both a DBUS and Modem API for AGPS support.
This proposal introduces two AGPS features:
1) Fine time injection - the cellular modem has access to accurate timing
information that can help a GPS device to get a quicker fix. If the modem and
GPS device are separate components a handshake mechanism is required to forward
the timing information from the modem to the GPS. A typical approach is to have
a hardware signal between the modem and GPS device that can carry a timing
pulse. In addition signalling through software is required to request such
timing pulse and to associate the correct Universal Time with the generated
pulse.
2) Control Plane Assistance Data and Position Requests - The Mobile Network is
able to provide assistance data for GPS devices through the control plane. This
assistance data can help a GPS device to get a quicker fix. In addition the
control plane can be used by the Mobile Network to request a GPS enabled
Mobile Device for its location. This latter functionality is needed to meet
E911 requirements [1]. A typical sequence looks as follow:
Mobile Network Mobile Device
--- Assistance Data ---
--- Position Request --
-- Position Response --
[1] http://en.wikipedia.org/wiki/Enhanced_911
Cheers,
Waldo
---
doc/agps-api.txt | 98 +++
include/agps.h | 135 ++
2 files changed, 233 insertions(+), 0 deletions(-) create mode 100644
doc/agps-api.txt create mode 100644 include/agps.h
diff --git a/doc/agps-api.txt b/doc/agps-api.txt new file mode 100644 index
000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===
+
+Serviceorg.ofono
+Interface org.ofono.AgpsManager
+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 SendLCSFrame(string framedata)
+
+ Send a LCS position protocol frame to the Mobile
+ Network. The LCS frame typically represents a
+ Position Response.
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ void RequestFineTimeInjection(uint16 pulselength)
+
+ Request modem to generate a fine time injection
+ pulse. pulselength is the duration of the pulse
+ expressed in radio frames.
+
+
+SignalsPropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ IncomingLCSFrame(string framedata)
+
+ LCS positioning protocol frame received from the
+ Mobile Network. The LCS frame typically represents
+ Assistance Data, a Position Request or a combination
+ of both.
+ The raw frame data is formatted as the concatenated
+ sequence of the two digit hexadecimal representation
+ of each of its octets. Example: 00FC2345
+
+ FineTimeInjectionNotification(dict radioframenumber)
+
+ Notification about fine time injection pulse
+ generated by modem.
RE: [RFC] AGPS Support
: -Original Message- : Behalf Of ext Joly, Frederic : -Original Message- : From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Marcel Holtmann : Sent: Wednesday, November 03, 2010 11:40 AM -- : Or do we expect oFono core to do something with this data? I am under : the impression that oFono core is just a pipe here. I would not expect oFono core to do anything with assistance data, last I looked oFono does not have positioning engine that needs helper data to enhance fix time. Positioning engine, whether in Linux or in GPR chip, interfaces user plane A-GPS OMA SUPL servers and control plane A-GPS (plus 3GPP commands) to cellular network residing servers. Both interfaces, in the end, point to 3GPP TS's with ASN.1 BER encoded content for assistance data. Control plane or user plane A-GPS servers do not do XML formats. Only 27.007 introduces format conversion. So raw pipe, as Sjur proposed, but with ASN.1 formatted payload without payload conversions in modem NOR in Linux side (oFono core, modem plugin or positioning engine) to XML. : And in conclusion we have XML and ASN.1 adding some overhead to the : actual data that is encoded. None of them is coming for free. : : If we wanna look at this not from the 27.007 standard angle, then we : have to look at what the users of this D-Bus are talking and what : would : be easiest for them. OMA SUPL specifications point to 3GPP 44.031 and TS 25.331. The common nominator for positioning engines is OMA and non-27.007 TS's use of ASN.1 formatted data. TS 27.007 from positioning user view is the odd standard. : As of today, I'm suspicious about proposing the XML format as the only : ofono solution. : Do we have commitments from GPS vendors or positioning framework : vendors or telephone integrators that they are going to use the XML : format? : Does STE GPS framework supports these XML formats? As above, positioning engine has to be ASN.1 capable when user plane A-GPS is used. Products over different mobile platforms do user plane A-GPS, control plane with AT interface introduced XML just adds overhead. Marko ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC] AGPS Support
Hi, Once again I apologise, I have not been able to react before on this. -Original Message- From: ofono-boun...@ofono.org [mailto:ofono-boun...@ofono.org] On Behalf Of Marcel Holtmann Sent: Wednesday, November 03, 2010 11:40 AM To: Sjur Brændeland Cc: Ahmed, Suhail; Simon ETHBRIDGE; mats.tun...@stericsson.com; ofono@ofono.org Subject: Re: [RFC] AGPS Support Or do we expect oFono core to do something with this data? I am under the impression that oFono core is just a pipe here. And in conclusion we have XML and ASN.1 adding some overhead to the actual data that is encoded. None of them is coming for free. If we wanna look at this not from the 27.007 standard angle, then we have to look at what the users of this D-Bus are talking and what would be easiest for them. These last sentences did not provoke any comments or reactions, but I would have expected they did because they are pointing out an important fact. Ofono, in this feature, is just a pipe. The choice for proposing ASN.1 containers or more exactly passing directing RRC frames, RRLP frames or other air interface protocols frames was driven by a simple fact: this data formatting can be easily supported, if not already supported, by nearly all the GPS vendors or positioning application frameworks, and this, thanks to the SUPL clients which are embedded inside positioning application frameworks or GPS daemons. Going to standard AT commands is virtuous, and all of us should support this. But the fact is that these AT commands for positioning support with xml dtd (CPOS and CPOSR) are a late addition of release 8 end of 2008 while the corresponding features had been introduced in the 3GPP standard 9 or 10 years ago (just check R99 04.31!). So the GPS and positioning industry had to find its own way before several years before the 3GPP minds proposing something. As of today, I'm suspicious about proposing the XML format as the only ofono solution. Do we have commitments from GPS vendors or positioning framework vendors or telephone integrators that they are going to use the XML format? Does STE GPS framework supports these XML formats? I think these considerations should be put in the balance before pushing a single solution. Thanks for reading me up to here, 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: [RFC] AGPS Support
Hi Marcel. On positioning framework side, XML containers encoding/decoding does not seem to be yet widely used, while the support of RRC and RRLP framing is common, thanks to the support of SUPL. Using XML and 27.007 format would be great as long as long as ofono is not obliged to interpret the XML containers. Denis, is this something you would consider as an option, to transport both ASN.1 coded RRC / RRLP frames and XML transparently over the oFono API ? can some just quickly summarize for me what kind of different data type representation we actually have here. And what the different modems and standard suggest on how to encode them. The RRLP, RRC and LPP standards all use ASN.1 to specify the data that is transferred, this encoded using packed en coding rules. The data is represented as SEQUENCES of INTEGER and ENUMERATED data types. A lot of items are subject to interesting scaling algorithms to get them into an integral format. A handful of items (locations and required assistance data) are effectively octet strings from other 3gpp standards. Most of the data is assistance data describing reference location, reference time, satellite orbits, expected doppler and code phase. The UE calculates the location and returns this as a GAD shape which is basically an ellipse with uncertainty, the coordinates scaled to be integral values. And then really who needs to transcode what in to what standard if we would be going for XML as format? The STE-Ericsson modem is doing the transcoding to XML on the modem side, using the 27.007 AT commands defined for AGPS. For other modems sending the raw RRC/RRLP frames I guess the transcoding to XML would need to happen in the ofono driver or in ofono core if you want to expose an oFono XML API. Regards, Sjur and Simon ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Sjur, On positioning framework side, XML containers encoding/decoding does not seem to be yet widely used, while the support of RRC and RRLP framing is common, thanks to the support of SUPL. Using XML and 27.007 format would be great as long as long as ofono is not obliged to interpret the XML containers. Denis, is this something you would consider as an option, to transport both ASN.1 coded RRC / RRLP frames and XML transparently over the oFono API ? can some just quickly summarize for me what kind of different data type representation we actually have here. And what the different modems and standard suggest on how to encode them. The RRLP, RRC and LPP standards all use ASN.1 to specify the data that is transferred, this encoded using packed en coding rules. The data is represented as SEQUENCES of INTEGER and ENUMERATED data types. A lot of items are subject to interesting scaling algorithms to get them into an integral format. A handful of items (locations and required assistance data) are effectively octet strings from other 3gpp standards. Most of the data is assistance data describing reference location, reference time, satellite orbits, expected doppler and code phase. The UE calculates the location and returns this as a GAD shape which is basically an ellipse with uncertainty, the coordinates scaled to be integral values. And then really who needs to transcode what in to what standard if we would be going for XML as format? The STE-Ericsson modem is doing the transcoding to XML on the modem side, using the 27.007 AT commands defined for AGPS. For other modems sending the raw RRC/RRLP frames I guess the transcoding to XML would need to happen in the ofono driver or in ofono core if you want to expose an oFono XML API. so here is my take on XML. If we have to parse it, then in general that is a bad idea. Creating XML is just fine. It is not something totally horrible, but nevertheless it is something that I would like to avoid. If we can assume that we can use GMarkup (and its restrictions) for it, then it mitigates this a little bit. That said, I am with Denis here. If XML is defined in 27.007, then it does make sense to do it. And as long as the core just sees it as a stream of bytes, I am fine with this. This of course means that the modems that don't use XML native for this have to do some transcoding here. That is then up to the modem driver. No on the other hand ASN.1 description of packets is also fine to me. However same rule applies that oFono core should not need to look into the data. It should just hand them off. Or do we expect oFono core to do something with this data? I am under the impression that oFono core is just a pipe here. And in conclusion we have XML and ASN.1 adding some overhead to the actual data that is encoded. None of them is coming for free. If we wanna look at this not from the 27.007 standard angle, then we have to look at what the users of this D-Bus are talking and what would be easiest for them. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Denis, What are the possible reasons as to why oFono might need to peek inside the XML? I was previously under the false impression that you wanted oFono API to export AGPS functionality using dbus types only. Piping the AGPS XML (or ASN.1 coded data) through oFono certainly makes the oFono implementation much simpler. I'm all for that :-) Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi, 2010/11/3 Sjur Brændeland sjurb...@gmail.com: I was previously under the false impression that you wanted oFono API to export AGPS functionality using dbus types only. Piping the AGPS XML (or ASN.1 coded data) through oFono certainly makes the oFono implementation much simpler. I'm all for that :-) I think it has been the working assumption to just forward raw data over D-Bus; PDU as an array of bytes. I believe the ISI modem interface exposes raw ASN.1 PDUs directly. Obviously we need to pick one format for the D-Bus interface, but I'm a little wary of transcoding between the two formats, be it in the core or in the drivers. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Aki, On 11/03/2010 12:40 PM, Aki Niemi wrote: Hi, 2010/11/3 Sjur Brændeland sjurb...@gmail.com: I was previously under the false impression that you wanted oFono API to export AGPS functionality using dbus types only. Piping the AGPS XML (or ASN.1 coded data) through oFono certainly makes the oFono implementation much simpler. I'm all for that :-) I think it has been the working assumption to just forward raw data over D-Bus; PDU as an array of bytes. I believe the ISI modem interface exposes raw ASN.1 PDUs directly. Obviously we need to pick one format for the D-Bus interface, but I'm a little wary of transcoding between the two formats, be it in the core or in the drivers. Oh I can definitely see that no matter which one we pick it will be inconvenient for some vendors. But I think we're all interested in picking one 'standard' one to avoid fragmentation. Are all vendors utilizing the same ASN.1 binary encoding format, or is that also variable between vendors? We already have a disaster with CAT spec using C-TLVs and BER-TLVs and it is a really bad idea to expose upper layers to these details. Can someone perform due diligence into what it would take to convert ASN.1 into XML? If the amount of work is not large, then it is another point for the XML / 27.007 approach. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC] AGPS Support
For other modems sending the raw RRC/RRLP frames I guess the transcoding to XML would need to happen in the ofono driver or in ofono core if you want to expose an oFono XML API. so here is my take on XML. If we have to parse it, then in general that is a bad idea. Creating XML is just fine. You need both as it's not only a matter of converting the raw RRC/RRLP frames from the modem to XML, but the responses from the GPS engine are presumably in XML format as well then and the modem driver would need to parse that and re-create RRC/RRLP frames again (for modem that expects raw RRC/RRLP frames). See the tables in section 8.55 of 27.007 for the XML schemas. It refers to the ASN.1 syntax for the definition of the value ranges. Cheers, Waldo ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Denis, Fredric wrote: On positioning framework side, XML containers encoding/decoding does not seem to be yet widely used, while the support of RRC and RRLP framing is common, thanks to the support of SUPL. Using XML and 27.007 format would be great as long as long as ofono is not obliged to interpret the XML containers. Denis, is this something you would consider as an option, to transport both ASN.1 coded RRC / RRLP frames and XML transparently over the oFono API ? Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Sjur, On positioning framework side, XML containers encoding/decoding does not seem to be yet widely used, while the support of RRC and RRLP framing is common, thanks to the support of SUPL. Using XML and 27.007 format would be great as long as long as ofono is not obliged to interpret the XML containers. Denis, is this something you would consider as an option, to transport both ASN.1 coded RRC / RRLP frames and XML transparently over the oFono API ? can some just quickly summarize for me what kind of different data type representation we actually have here. And what the different modems and standard suggest on how to encode them. And then really who needs to transcode what in to what standard if we would be going for XML as format? Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Sjur, On 11/02/2010 03:36 PM, Sjur Brændeland wrote: Hi Denis, Fredric wrote: On positioning framework side, XML containers encoding/decoding does not seem to be yet widely used, while the support of RRC and RRLP framing is common, thanks to the support of SUPL. Using XML and 27.007 format would be great as long as long as ofono is not obliged to interpret the XML containers. Denis, is this something you would consider as an option, to transport both ASN.1 coded RRC / RRLP frames and XML transparently over the oFono API ? The question here is really about what has the best chance of being accepted as 'official' API prefixed with org.ofono. I don't see the binary variant having a chance of being accepted right now. With XML I can see it becoming the official API since it is defined by 27.007. Having said that, both can indeed co-exist side-by-side. What are the possible reasons as to why oFono might need to peek inside the XML? Regards, Sjur Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC] AGPS Support
Hi Bastian,
Bastian, Waldo wrote:
Please find attached a proposal for both a DBUS and Modem API for AGPS
support. There are some minor changes compared to the proposal from
May 14, 2010.
...
void SendLCSFrame(string frametype, string framedata)
Send a LCS position protocol frame to the Mobile
Network. The LCS frame typically represents a
Position Response.
Valid frametypes are:
rrlp_measure_position_response
rrc_measurement_report
The raw frame data is formatted as the concatenated
sequence of the two digit hexadecimal representation
of each of its octets. Example: 00FC2345
struct ofono_lcs_frame {
enum ofono_lcs_frame_type lcs_frame_type;
int frame_length; /* size of raw_frame in bytes */
unsigned char* raw_frame;
};
The 27.007 Spec specifies positioning request/responses for AT where
Positioning data are coded in XML data structures.
I think the oFono interface should not use binary data, but rather be aligned
with 27.007
and present decoded data as DBUS typed signals and methods with the same
information
content as specified in the XML data for AT+CPOS, AT+CPOSR.
In this way the vanilla AT driver could handle the CPOS, CPOR AT-commands
and code/decode between XML and explicit data structures, which in turn
oFono Core could code/decode as DBUS data types.
Regards,
Sjur Brændeland
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC] AGPS Support
Hi Sjur, The 27.007 Spec specifies positioning request/responses for AT where Positioning data are coded in XML data structures. I think the oFono interface should not use binary data, but rather be aligned with 27.007 and present decoded data as DBUS typed signals and methods with the same information content as specified in the XML data for AT+CPOS, AT+CPOSR. This was proposed several times. The main objections against the XML file format was the difficulty of parsing such a beast and support of it by modem vendors. Personally (and this is based on rather limited experience with this area) I'm not against the idea; it fits with oFono's overall strategy of following 27.007 whenever possible... Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
