10:09 a.m.
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
3:57 p.m.
New subject: [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
9:39 a.m.
New subject: [RFC] AGPS Support
Hi
My two cents...
-----Original Message-----
> 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...
AFAIK, it does not exist a free standard API for satellite measurements and GPS assistance
data. Moreover, while Galileo and Compass GNSS are not yet deployed, GLONASS support will
be soon a need.
So, the idea is to not interpret positioning data or request and to pass them
transparently from the modem to the positioning framework and vis versa.
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.
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.
8:36 p.m.
New subject: [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
8:44 p.m.
New subject: [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
10:27 a.m.
New subject: [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
10:39 a.m.
New subject: [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
6:59 p.m.
New subject: [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
7:04 p.m.
New subject: [RFC] AGPS Support
Hi Waldo,
> > 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.
and so is parsing of ASN.1 actually. Since oFono core will not look into
this and treat it as a stream of bytes, we will have to make one modem
vendor suffer more than others.
So what is useful for the applications using this D-Bus based API?
Regards
Marcel
10:52 p.m.
New subject: [RFC] AGPS Support
Hi,
Once again I apologise, I have not been able to react before on this.
-----Original Message-----
From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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.tuneld(a)stericsson.com; ofono(a)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.
5:17 p.m.
New subject: [RFC] AGPS Support
: -----Original Message-----
: Behalf Of ext Joly, Frederic
: > -----Original Message-----
: > From: ofono-bounces(a)ofono.org [mailto:ofono-bounces@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
8:50 p.m.
New subject: [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
11:27 a.m.
New subject: [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
5:40 p.m.
New subject: [RFC] AGPS Support
Hi,
2010/11/3 Sjur Brændeland <sjurbren(a)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
5:55 p.m.
New subject: [RFC] AGPS Support
Hi Aki,
On 11/03/2010 12:40 PM, Aki Niemi wrote:
Hi,
2010/11/3 Sjur Brændeland <sjurbren(a)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
3979
days inactive
4018
days old
14 comments
8 participants
participants (8)
-
Aki Niemi -
Bastian, Waldo -
Denis Kenzior -
Joly, Frederic -
Marcel Holtmann -
Marko.Ovaska＠nokia.com -
Sjur BRENDELAND -
Sjur Brændeland