[RFC] AGPS support

[RFC] AGPS support

[Bastian, Waldo]

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

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 0000000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===============
+
+Service		org.ofono
+Interface	org.ofono.AgpsManager
+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 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.
+
+
+Signals		PropertyChanged(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. The radioframenumber dict
+			is defined as follow:
+
+			string AccessTechnology
+				"gsm" or "umts"
+			
+			uint32 TdmaFrameNumber (gsm only)
+				range 0 - 2715647 (2048*26*51)
+
+			uint16 TdmaTimeslot (gsm only)
+				range 0 - 7
+
+			uint16 TimeslotBit (gsm only)
+				range 0 - 156
+
+			uint16 TimingAdvance (gsm only)
+				range 0 - 63
+
+			uint16 BcchArfcn (gsm only)
+				range 0 - 1023
+
+			uint16 Bsic (gsm only)
+				range 0 - 64
+
+			uint16 Sfn (umts only)
+				range 0 - 4095
+
+			string RrcState (umts only)
+				"cell_dch", "cell_fach", "cell_pch" or
+				"ura_pch"
+			
+			uint16 RoundTripTime (umts only)
+				range 0 - 32766
+
+
+Properties	boolean LcsEnabled [readwrite]
+
+			If LcsEnabled is False, then no LCS positioning
+			protocol frames are received.
+
diff --git a/include/agps.h b/include/agps.h
new file mode 100644
index 0000000..07a0fb2
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,135 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifndef __OFONO_AGPS_H
+#define __OFONO_AGPS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+
+struct ofono_agps;
+
+enum ofono_rrc_state {
+	RRC_CELL_PCH = 0,
+	RRC_CELL_FACH = 1,
+	RRC_CELL_DCH = 2,
+	RRC_URA_PCH = 3,
+};
+
+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;
+};
+
+struct ofono_lcs_gsm_fn {
+	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
+	int TDMA_timeslot;	/* range 0 - 7 */
+	int timeslot_bit;	/* range 0 - 156 */
+	int timing_advance;	/* range 0 - 63 */
+	int bcch_arfcn;		/* range 0 - 1023 */
+	int bsic;		/* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+	int sfn;		/* range 0 - 4095 */
+	int rrc_state;		/* enum ofono_rrc_state */
+	int round_trip_time;	/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+	int radio_access_technology; /* enum access_technology */
+	union {
+		ofono_lcs_gsm_fn	gsm_frame_number;
+		ofono_lcs_utran_fn	utran_frame_number;
+	}
+};	
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+				void *data);
+
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+				struct ofono_lcs_radio_fn *radio_frame_number,
+				void *data);
+
+/* AGPS related functions, including LCS frame forwarding and fine time injection
+ */
+struct ofono_agps_driver {
+	const char *name;
+	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+			void *data);
+	void (*remove)(struct ofono_agps *agps);
+
+	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+	void (*send_lcs_frame)(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */,
+			ofono_agps_send_lcs_frame_cb_t cb, void *data);
+			
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idae of
+	 * Universal Time, it indicates at which radio frame number it
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */ 
+	void (*inject_time)(struct ofono_agps *agps,
+			int radio_access_technology, /* enum access_technology */
+			int pulse_length, /* duration of pulse in radio slots */
+			ofono_agps_inject_time_cb_t cb, void *data);
+};
+
+void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */);
+
+int ofono_agps_driver_register(const struct ofono_agps_driver *d);
+void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
+
+struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
+						unsigned int vendor,
+						const char *driver,
+						void *data);
+
+void ofono_agps_register(struct ofono_agps *agps);
+void ofono_agps_remove(struct ofono_agps *agps);
+
+void ofono_agps_set_data(struct ofono_agps *agps, void *data);
+void *ofono_agps_get_data(struct ofono_agps *agps);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_AGPS_H */
-- 
1.5.4.3


[-- Attachment #2: 0001-Add-DBUS-and-Modem-API-for-AGPS-support.patch --]
[-- Type: application/octet-stream, Size: 7901 bytes --]

From b7486c8360cda212b7d9342156e451f0ea47b61a Mon Sep 17 00:00:00 2001
From: Waldo Bastian <waldo.bastian@intel.com>
Date: Fri, 14 May 2010 17:26:44 -0700
Subject: [PATCH] Add DBUS and Modem API for AGPS support.

---
 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 0000000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===============
+
+Service		org.ofono
+Interface	org.ofono.AgpsManager
+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 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.
+
+
+Signals		PropertyChanged(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. The radioframenumber dict
+			is defined as follow:
+
+			string AccessTechnology
+				"gsm" or "umts"
+			
+			uint32 TdmaFrameNumber (gsm only)
+				range 0 - 2715647 (2048*26*51)
+
+			uint16 TdmaTimeslot (gsm only)
+				range 0 - 7
+
+			uint16 TimeslotBit (gsm only)
+				range 0 - 156
+
+			uint16 TimingAdvance (gsm only)
+				range 0 - 63
+
+			uint16 BcchArfcn (gsm only)
+				range 0 - 1023
+
+			uint16 Bsic (gsm only)
+				range 0 - 64
+
+			uint16 Sfn (umts only)
+				range 0 - 4095
+
+			string RrcState (umts only)
+				"cell_dch", "cell_fach", "cell_pch" or
+				"ura_pch"
+			
+			uint16 RoundTripTime (umts only)
+				range 0 - 32766
+
+
+Properties	boolean LcsEnabled [readwrite]
+
+			If LcsEnabled is False, then no LCS positioning
+			protocol frames are received.
+
diff --git a/include/agps.h b/include/agps.h
new file mode 100644
index 0000000..07a0fb2
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,135 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ *
+ */
+
+#ifndef __OFONO_AGPS_H
+#define __OFONO_AGPS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+
+struct ofono_agps;
+
+enum ofono_rrc_state {
+	RRC_CELL_PCH = 0,
+	RRC_CELL_FACH = 1,
+	RRC_CELL_DCH = 2,
+	RRC_URA_PCH = 3,
+};
+
+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;
+};
+
+struct ofono_lcs_gsm_fn {
+	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
+	int TDMA_timeslot;	/* range 0 - 7 */
+	int timeslot_bit;	/* range 0 - 156 */
+	int timing_advance;	/* range 0 - 63 */
+	int bcch_arfcn;		/* range 0 - 1023 */
+	int bsic;		/* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+	int sfn;		/* range 0 - 4095 */
+	int rrc_state;		/* enum ofono_rrc_state */
+	int round_trip_time;	/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+	int radio_access_technology; /* enum access_technology */
+	union {
+		ofono_lcs_gsm_fn	gsm_frame_number;
+		ofono_lcs_utran_fn	utran_frame_number;
+	}
+};	
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+				void *data);
+
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+				struct ofono_lcs_radio_fn *radio_frame_number,
+				void *data);
+
+/* AGPS related functions, including LCS frame forwarding and fine time injection
+ */
+struct ofono_agps_driver {
+	const char *name;
+	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+			void *data);
+	void (*remove)(struct ofono_agps *agps);
+
+	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+	void (*send_lcs_frame)(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */,
+			ofono_agps_send_lcs_frame_cb_t cb, void *data);
+			
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idae of
+	 * Universal Time, it indicates at which radio frame number it
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */ 
+	void (*inject_time)(struct ofono_agps *agps,
+			int radio_access_technology, /* enum access_technology */
+			int pulse_length, /* duration of pulse in radio slots */
+			ofono_agps_inject_time_cb_t cb, void *data);
+};
+
+void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */);
+
+int ofono_agps_driver_register(const struct ofono_agps_driver *d);
+void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
+
+struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
+						unsigned int vendor,
+						const char *driver,
+						void *data);
+
+void ofono_agps_register(struct ofono_agps *agps);
+void ofono_agps_remove(struct ofono_agps *agps);
+
+void ofono_agps_set_data(struct ofono_agps *agps, void *data);
+void *ofono_agps_get_data(struct ofono_agps *agps);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_AGPS_H */
-- 
1.5.4.3

RE: [RFC] AGPS support

[Joly, Frederic]

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

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(a)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 0000000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===============
+
+Service		org.ofono
+Interface	org.ofono.AgpsManager
+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 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.
+
+
+Signals		PropertyChanged(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. The radioframenumber dict
+			is defined as follow:
+
+			string AccessTechnology
+				"gsm" or "umts"
+			
+			uint32 TdmaFrameNumber (gsm only)
+				range 0 - 2715647 (2048*26*51)
+
+			uint16 TdmaTimeslot (gsm only)
+				range 0 - 7
+
+			uint16 TimeslotBit (gsm only)
+				range 0 - 156
+
+			uint16 TimingAdvance (gsm only)
+				range 0 - 63
+
+			uint16 BcchArfcn (gsm only)
+				range 0 - 1023
+
+			uint16 Bsic (gsm only)
+				range 0 - 64
+
+			uint16 Sfn (umts only)
+				range 0 - 4095
+
+			string RrcState (umts only)
+				"cell_dch", "cell_fach", "cell_pch" or
+				"ura_pch"
+			
+			uint16 RoundTripTime (umts only)
+				range 0 - 32766
+
+
+Properties	boolean LcsEnabled [readwrite]
+
+			If LcsEnabled is False, then no LCS positioning
+			protocol frames are received.
+
diff --git a/include/agps.h b/include/agps.h new file mode 100644 index 0000000..07a0fb2
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,135 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or 
+modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  
+02110-1301  USA
+ *
+ */
+
+#ifndef __OFONO_AGPS_H
+#define __OFONO_AGPS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+
+struct ofono_agps;
+
+enum ofono_rrc_state {
+	RRC_CELL_PCH = 0,
+	RRC_CELL_FACH = 1,
+	RRC_CELL_DCH = 2,
+	RRC_URA_PCH = 3,
+};
+
+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;
+};
+
+struct ofono_lcs_gsm_fn {
+	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
+	int TDMA_timeslot;	/* range 0 - 7 */
+	int timeslot_bit;	/* range 0 - 156 */
+	int timing_advance;	/* range 0 - 63 */
+	int bcch_arfcn;		/* range 0 - 1023 */
+	int bsic;		/* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+	int sfn;		/* range 0 - 4095 */
+	int rrc_state;		/* enum ofono_rrc_state */
+	int round_trip_time;	/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+	int radio_access_technology; /* enum access_technology */
+	union {
+		ofono_lcs_gsm_fn	gsm_frame_number;
+		ofono_lcs_utran_fn	utran_frame_number;
+	}
+};	
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+				void *data);
+
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+				struct ofono_lcs_radio_fn *radio_frame_number,
+				void *data);
+
+/* AGPS related functions, including LCS frame forwarding and fine time 
+injection  */ struct ofono_agps_driver {
+	const char *name;
+	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+			void *data);
+	void (*remove)(struct ofono_agps *agps);
+
+	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+	void (*send_lcs_frame)(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */,
+			ofono_agps_send_lcs_frame_cb_t cb, void *data);
+			
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idae of
+	 * Universal Time, it indicates at which radio frame number it
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */ 
+	void (*inject_time)(struct ofono_agps *agps,
+			int radio_access_technology, /* enum access_technology */
+			int pulse_length, /* duration of pulse in radio slots */
+			ofono_agps_inject_time_cb_t cb, void *data); };
+
+void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */);
+
+int ofono_agps_driver_register(const struct ofono_agps_driver *d); void 
+ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
+
+struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
+						unsigned int vendor,
+						const char *driver,
+						void *data);
+
+void ofono_agps_register(struct ofono_agps *agps); void 
+ofono_agps_remove(struct ofono_agps *agps);
+
+void ofono_agps_set_data(struct ofono_agps *agps, void *data); void 
+*ofono_agps_get_data(struct ofono_agps *agps);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_AGPS_H */
--
1.5.4.3

---------------------------------------------------------------------
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: [RFC] AGPS support

[Joly, Frederic]

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

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 but before 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(a)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 0000000..7245eac
--- /dev/null
+++ b/doc/agps-api.txt
@@ -0,0 +1,98 @@
+AgpsManager hierarchy
+===============
+
+Service		org.ofono
+Interface	org.ofono.AgpsManager
+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 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.
+
+
+Signals		PropertyChanged(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. The radioframenumber dict
+			is defined as follow:
+
+			string AccessTechnology
+				"gsm" or "umts"
+			
+			uint32 TdmaFrameNumber (gsm only)
+				range 0 - 2715647 (2048*26*51)
+
+			uint16 TdmaTimeslot (gsm only)
+				range 0 - 7
+
+			uint16 TimeslotBit (gsm only)
+				range 0 - 156
+
+			uint16 TimingAdvance (gsm only)
+				range 0 - 63
+
+			uint16 BcchArfcn (gsm only)
+				range 0 - 1023
+
+			uint16 Bsic (gsm only)
+				range 0 - 64
+
+			uint16 Sfn (umts only)
+				range 0 - 4095
+
+			string RrcState (umts only)
+				"cell_dch", "cell_fach", "cell_pch" or
+				"ura_pch"
+			
+			uint16 RoundTripTime (umts only)
+				range 0 - 32766
+
+
+Properties	boolean LcsEnabled [readwrite]
+
+			If LcsEnabled is False, then no LCS positioning
+			protocol frames are received.
+
diff --git a/include/agps.h b/include/agps.h new file mode 100644 index 0000000..07a0fb2
--- /dev/null
+++ b/include/agps.h
@@ -0,0 +1,135 @@
+/*
+ *
+ *  oFono - Open Source Telephony
+ *
+ *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or 
+modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  
+02110-1301  USA
+ *
+ */
+
+#ifndef __OFONO_AGPS_H
+#define __OFONO_AGPS_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+
+struct ofono_agps;
+
+enum ofono_rrc_state {
+	RRC_CELL_PCH = 0,
+	RRC_CELL_FACH = 1,
+	RRC_CELL_DCH = 2,
+	RRC_URA_PCH = 3,
+};
+
+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;
+};
+
+struct ofono_lcs_gsm_fn {
+	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
+	int TDMA_timeslot;	/* range 0 - 7 */
+	int timeslot_bit;	/* range 0 - 156 */
+	int timing_advance;	/* range 0 - 63 */
+	int bcch_arfcn;		/* range 0 - 1023 */
+	int bsic;		/* range 0 - 64 */
+};
+
+struct ofono_lcs_utran_fn {
+	int sfn;		/* range 0 - 4095 */
+	int rrc_state;		/* enum ofono_rrc_state */
+	int round_trip_time;	/* range 0 - 32766 */
+};
+
+struct ofono_lcs_radio_fn {
+	int radio_access_technology; /* enum access_technology */
+	union {
+		ofono_lcs_gsm_fn	gsm_frame_number;
+		ofono_lcs_utran_fn	utran_frame_number;
+	}
+};	
+
+typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
+				void *data);
+
+typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
+				struct ofono_lcs_radio_fn *radio_frame_number,
+				void *data);
+
+/* AGPS related functions, including LCS frame forwarding and fine time 
+injection  */ struct ofono_agps_driver {
+	const char *name;
+	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
+			void *data);
+	void (*remove)(struct ofono_agps *agps);
+
+	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);
+
+	/* Assistance Data and Position Requests from the Mobile Network are
+	 * signalled via the ofono_agps_lcs_frame_notify function and the
+	 * oFono core to an external GPS manager. This GPS manager can reply
+	 * to Position Requests with one or more Position Responses which
+	 * are then send back to the modem via the send_lcs_frame function.
+	 */
+	void (*send_lcs_frame)(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */,
+			ofono_agps_send_lcs_frame_cb_t cb, void *data);
+			
+	/* The GPS manager can ask the modem to generate a HW pulse (time
+	 * stamp) with a defined length and the modem replies indicates when
+	 * it generates the pulse. But as the modem has no precise idae of
+	 * Universal Time, it indicates at which radio frame number it
+	 * generated the pulse. The GPS manager which knows the link between
+	 * Universal Time and the Radio Frame number knows very precisely at
+	 * what time the pulse was generated and its duration.
+	 *
+	 * Timing accuracy is typically a few microseconds.
+	 */ 
+	void (*inject_time)(struct ofono_agps *agps,
+			int radio_access_technology, /* enum access_technology */
+			int pulse_length, /* duration of pulse in radio slots */
+			ofono_agps_inject_time_cb_t cb, void *data); };
+
+void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
+			int frame_length, /* size of frame_data in bytes */
+			unsigned char* frame_data /* raw frame data */);
+
+int ofono_agps_driver_register(const struct ofono_agps_driver *d); void 
+ofono_agps_driver_unregister(const struct ofono_agps_driver *d);
+
+struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
+						unsigned int vendor,
+						const char *driver,
+						void *data);
+
+void ofono_agps_register(struct ofono_agps *agps); void 
+ofono_agps_remove(struct ofono_agps *agps);
+
+void ofono_agps_set_data(struct ofono_agps *agps, void *data); void 
+*ofono_agps_get_data(struct ofono_agps *agps);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_AGPS_H */
--
1.5.4.3

---------------------------------------------------------------------
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: [RFC] AGPS support

[Marcel Holtmann]

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

Hi Fred,

> 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 but before 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.

gently reminder to not use top posting on a public open source mailing
list. We expect proper inline quoting.

Regards

Marcel

RE: [RFC] AGPS Support

[Marko.Ovaska]

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



: -----Original Message-----
: Behalf Of ext Joly, Frederic

: > -----Original Message-----
: > From: ofono-bounces(a)ofono.org [mailto:ofono-bounces(a)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

RE: [RFC] AGPS Support

[Joly, Frederic]

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

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(a)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.

RE: [RFC] AGPS Support

[Marcel Holtmann]

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

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

RE: [RFC] AGPS Support

[Bastian, Waldo]

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

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

Re: [RFC] AGPS Support

[Denis Kenzior]

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

Hi Aki,

On 11/03/2010 12:40 PM, Aki Niemi wrote:
> Hi,
> 
> 2010/11/3 Sjur Brændeland <sjurbren@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

Re: [RFC] AGPS Support

[Aki Niemi]

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

Hi,

2010/11/3 Sjur Brændeland <sjurbren@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

Re: [RFC] AGPS Support

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

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

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

Re: [RFC] AGPS Support

[Marcel Holtmann]

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

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

Re: [RFC] AGPS Support

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

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

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

Re: [RFC] AGPS Support

[Denis Kenzior]

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

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

Re: [RFC] AGPS Support

[Marcel Holtmann]

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

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

Re: [RFC] AGPS Support

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

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

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

RE: [RFC] AGPS Support

[Joly, Frederic]

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

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.

Re: [RFC] AGPS Support

[Denis Kenzior]

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

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

RE: [RFC] AGPS Support

[Sjur BRENDELAND]

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

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

[RFC] AGPS Support

[Bastian, Waldo]

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

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.

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

Proposed DBUS API:

AgpsManager hierarchy
=====================

Service		org.ofono
Interface	org.ofono.AgpsManager
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 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"

		void RequestFineTimeInjection(string rat, uint16 pulselength)

			Request modem to generate a fine time injection
			pulse. pulselength is the duration of the pulse
			expressed in radio frames.

			rat specifies the access technology used to derive
			the pulse from and can be "gsm" or "umts".
			If the requested access technology is not currently
			in use an error is returned.

Signals		PropertyChanged(string name, variant value)

			This signal indicates a changed value of the given
			property.

		IncomingLCSFrame(string frametypes, string framedata)

			LCS positioning protocol frame received from the
			Mobile Network.

			Valid frametypes for the LCS frame are:
				rrlp_assistance_data
				rrlp_measure_position_request
				rrc_assistance_data_delivery
				rrc_measurement_control

			Note that position/measurement requests can include
			assistance data as well.

			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. The radioframenumber dict
			is defined as follow:

			string AccessTechnology
				"gsm" or "umts"
			
			uint32 TdmaFrameNumber (gsm only)
				range 0 - 2715647 (2048*26*51)

			uint16 TdmaTimeslot (gsm only)
				range 0 - 7

			uint16 TimeslotBit (gsm only)
				range 0 - 156

			uint16 TimingAdvance (gsm only)
				range 0 - 63

			uint16 BcchArfcn (gsm only)
				range 0 - 1023

			uint16 Bsic (gsm only)
				range 0 - 64

			uint16 Sfn (umts only)
				range 0 - 4095

			string RrcState (umts only)
				"cell_dch", "cell_fach", "cell_pch" or
				"ura_pch"
			
			uint16 RoundTripTime (umts only)
				range 0 - 32766


Properties	boolean LcsEnabled [readwrite]

			If LcsEnabled is False, then no LCS positioning
			protocol frames are received.



Proposed Modem driver API:

/*
 *
 *  oFono - Open Source Telephony
 *
 *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License version 2 as
 *  published by the Free Software Foundation.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 *
 */

#ifndef __OFONO_AGPS_H
#define __OFONO_AGPS_H

#ifdef __cplusplus
extern "C" {
#endif

#include <ofono/types.h>

struct ofono_agps;

enum ofono_lcs_frame_type {
	RRLP_ASSISTANCE_DATA = 0,		/* from modem */
	/* Position request can include assistance data as well */
	RRLP_MEASURE_POSITION_REQUEST = 1,	/* from modem */
	RRLP_MEASURE_POSITION_RESPONSE = 2,	/* from GPS */
	RRC_ASSISTANCE_DATA_DELIVERY = 3,	/* from modem */
	/* Measurement control can include assistance data as well */
	RRC_MEASUREMENT_CONTROL = 4,		/* from modem */
	RRC_MEASUREMENT_REPORT = 5,		/* frop GPS */
};

enum ofono_rrc_state {
	RRC_CELL_PCH = 0,
	RRC_CELL_FACH = 1,
	RRC_CELL_DCH = 2,
	RRC_URA_PCH = 3,
};

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;
};

struct ofono_lcs_gsm_fn {
	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
	int TDMA_timeslot;	/* range 0 - 7 */
	int timeslot_bit;	/* range 0 - 156 */
	int timing_advance;	/* range 0 - 63 */
	int bcch_arfcn;		/* range 0 - 1023 */
	int bsic;		/* range 0 - 64 */
};

struct ofono_lcs_utran_fn {
	int sfn;		/* range 0 - 4095 */
	int rrc_state;		/* enum ofono_rrc_state */
	int round_trip_time;	/* range 0 - 32766 */
};

struct ofono_lcs_radio_fn {
	int radio_access_technology; /* enum access_technology */
	union {
		struct ofono_lcs_gsm_fn		gsm_frame_number;
		struct ofono_lcs_utran_fn	utran_frame_number;
	};
};	

typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
				void *data);

typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
				struct ofono_lcs_radio_fn *radio_frame_number,
				void *data);

/* AGPS related functions, including LCS frame forwarding and fine time injection
 */
struct ofono_agps_driver {
	const char *name;
	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
			void *data);
	void (*remove)(struct ofono_agps *agps);

	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);

	/* Assistance Data and Position Requests from the Mobile Network are
	 * signalled via the ofono_agps_lcs_frame_notify function and the
	 * oFono core to an external GPS manager. This GPS manager can reply
	 * to Position Requests with one or more Position Responses which
	 * are then send back to the modem via the send_lcs_frame function.
	 */
	void (*send_lcs_frame)(struct ofono_agps *agps,
			struct ofono_lcs_frame *frame,
			ofono_agps_send_lcs_frame_cb_t cb, void *data);
			
	/* The GPS manager can ask the modem to generate a HW pulse (time
	 * stamp) with a defined length and the modem replies indicates when
	 * it generates the pulse. But as the modem has no precise idae of
	 * Universal Time, it indicates at which radio frame number it
	 * generated the pulse. The GPS manager which knows the link between
	 * Universal Time and the Radio Frame number knows very precisely at
	 * what time the pulse was generated and its duration.
	 *
	 * Timing accuracy is typically a few microseconds.
	 */ 
	void (*inject_time)(struct ofono_agps *agps,
			int radio_access_technology, /* enum access_technology */
			int pulse_length, /* duration of pulse in radio slots */
			ofono_agps_inject_time_cb_t cb, void *data);
};

void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
			struct ofono_lcs_frame frame);

int ofono_agps_driver_register(const struct ofono_agps_driver *d);
void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);

struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
						unsigned int vendor,
						const char *driver,
						void *data);

void ofono_agps_register(struct ofono_agps *agps);
void ofono_agps_remove(struct ofono_agps *agps);

void ofono_agps_set_data(struct ofono_agps *agps, void *data);
void *ofono_agps_get_data(struct ofono_agps *agps);

#ifdef __cplusplus
}
#endif

#endif /* __OFONO_AGPS_H */



[-- Attachment #2: agps-api.txt --]
[-- Type: text/plain, Size: 2991 bytes --]

AgpsManager hierarchy
=====================

Service		org.ofono
Interface	org.ofono.AgpsManager
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 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"

		void RequestFineTimeInjection(string rat, uint16 pulselength)

			Request modem to generate a fine time injection
			pulse. pulselength is the duration of the pulse
			expressed in radio frames.

			rat specifies the access technology used to derive
			the pulse from and can be "gsm" or "umts".
			If the requested access technology is not currently
			in use an error is returned.

Signals		PropertyChanged(string name, variant value)

			This signal indicates a changed value of the given
			property.

		IncomingLCSFrame(string frametypes, string framedata)

			LCS positioning protocol frame received from the
			Mobile Network.

			Valid frametypes for the LCS frame are:
				rrlp_assistance_data
				rrlp_measure_position_request
				rrc_assistance_data_delivery
				rrc_measurement_control

			Note that position/measurement requests can include
			assistance data as well.

			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. The radioframenumber dict
			is defined as follow:

			string AccessTechnology
				"gsm" or "umts"
			
			uint32 TdmaFrameNumber (gsm only)
				range 0 - 2715647 (2048*26*51)

			uint16 TdmaTimeslot (gsm only)
				range 0 - 7

			uint16 TimeslotBit (gsm only)
				range 0 - 156

			uint16 TimingAdvance (gsm only)
				range 0 - 63

			uint16 BcchArfcn (gsm only)
				range 0 - 1023

			uint16 Bsic (gsm only)
				range 0 - 64

			uint16 Sfn (umts only)
				range 0 - 4095

			string RrcState (umts only)
				"cell_dch", "cell_fach", "cell_pch" or
				"ura_pch"
			
			uint16 RoundTripTime (umts only)
				range 0 - 32766


Properties	boolean LcsEnabled [readwrite]

			If LcsEnabled is False, then no LCS positioning
			protocol frames are received.


[-- Attachment #3: agps.h --]
[-- Type: text/plain, Size: 4685 bytes --]

/*
 *
 *  oFono - Open Source Telephony
 *
 *  Copyright (C) 2008-2010  Intel Corporation. All rights reserved.
 *
 *  This program is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License version 2 as
 *  published by the Free Software Foundation.
 *
 *  This program is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this program; if not, write to the Free Software
 *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 *
 */

#ifndef __OFONO_AGPS_H
#define __OFONO_AGPS_H

#ifdef __cplusplus
extern "C" {
#endif

#include <ofono/types.h>

struct ofono_agps;

enum ofono_lcs_frame_type {
	RRLP_ASSISTANCE_DATA = 0,		/* from modem */
	/* Position request can include assistance data as well */
	RRLP_MEASURE_POSITION_REQUEST = 1,	/* from modem */
	RRLP_MEASURE_POSITION_RESPONSE = 2,	/* from GPS */
	RRC_ASSISTANCE_DATA_DELIVERY = 3,	/* from modem */
	/* Measurement control can include assistance data as well */
	RRC_MEASUREMENT_CONTROL = 4,		/* from modem */
	RRC_MEASUREMENT_REPORT = 5,		/* frop GPS */
};

enum ofono_rrc_state {
	RRC_CELL_PCH = 0,
	RRC_CELL_FACH = 1,
	RRC_CELL_DCH = 2,
	RRC_URA_PCH = 3,
};

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;
};

struct ofono_lcs_gsm_fn {
	int TDMA_frame_number;	/* range 0 - 2715647 (2048*26*51) */
	int TDMA_timeslot;	/* range 0 - 7 */
	int timeslot_bit;	/* range 0 - 156 */
	int timing_advance;	/* range 0 - 63 */
	int bcch_arfcn;		/* range 0 - 1023 */
	int bsic;		/* range 0 - 64 */
};

struct ofono_lcs_utran_fn {
	int sfn;		/* range 0 - 4095 */
	int rrc_state;		/* enum ofono_rrc_state */
	int round_trip_time;	/* range 0 - 32766 */
};

struct ofono_lcs_radio_fn {
	int radio_access_technology; /* enum access_technology */
	union {
		struct ofono_lcs_gsm_fn		gsm_frame_number;
		struct ofono_lcs_utran_fn	utran_frame_number;
	};
};	

typedef void (*ofono_agps_send_lcs_frame_cb_t)(const struct ofono_error *error,
				void *data);

typedef void (*ofono_agps_inject_time_cb_t)(const struct ofono_error *error,
				struct ofono_lcs_radio_fn *radio_frame_number,
				void *data);

/* AGPS related functions, including LCS frame forwarding and fine time injection
 */
struct ofono_agps_driver {
	const char *name;
	int (*probe)(struct ofono_agps *agps, unsigned int vendor,
			void *data);
	void (*remove)(struct ofono_agps *agps);

	void (*receive_lcs_frames)(struct ofono_agps *agps, int enabled);

	/* Assistance Data and Position Requests from the Mobile Network are
	 * signalled via the ofono_agps_lcs_frame_notify function and the
	 * oFono core to an external GPS manager. This GPS manager can reply
	 * to Position Requests with one or more Position Responses which
	 * are then send back to the modem via the send_lcs_frame function.
	 */
	void (*send_lcs_frame)(struct ofono_agps *agps,
			struct ofono_lcs_frame *frame,
			ofono_agps_send_lcs_frame_cb_t cb, void *data);
			
	/* The GPS manager can ask the modem to generate a HW pulse (time
	 * stamp) with a defined length and the modem replies indicates when
	 * it generates the pulse. But as the modem has no precise idae of
	 * Universal Time, it indicates at which radio frame number it
	 * generated the pulse. The GPS manager which knows the link between
	 * Universal Time and the Radio Frame number knows very precisely at
	 * what time the pulse was generated and its duration.
	 *
	 * Timing accuracy is typically a few microseconds.
	 */ 
	void (*inject_time)(struct ofono_agps *agps,
			int radio_access_technology, /* enum access_technology */
			int pulse_length, /* duration of pulse in radio slots */
			ofono_agps_inject_time_cb_t cb, void *data);
};

void ofono_agps_lcs_frame_notify(struct ofono_agps *agps,
			struct ofono_lcs_frame frame);

int ofono_agps_driver_register(const struct ofono_agps_driver *d);
void ofono_agps_driver_unregister(const struct ofono_agps_driver *d);

struct ofono_agps *ofono_agps_create(struct ofono_modem *modem,
						unsigned int vendor,
						const char *driver,
						void *data);

void ofono_agps_register(struct ofono_agps *agps);
void ofono_agps_remove(struct ofono_agps *agps);

void ofono_agps_set_data(struct ofono_agps *agps, void *data);
void *ofono_agps_get_data(struct ofono_agps *agps);

#ifdef __cplusplus
}
#endif

#endif /* __OFONO_AGPS_H */