12:27 a.m.
This series of patches implements an interface for client
application to fetch the ECID information of neighboring
cells using DBUS.
include/cell-info.h | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++
src/cell-info.c | 512 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
include/dbus.h | 1 +
src/ofono.h | 1 +
Makefile.am | 8 +++++---
doc/cell-info.txt | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++
12:27 a.m.
New subject: [PATCH 1/5] cell-info: Header file for cell info atom
---
include/cell-info.h | 128 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 128 insertions(+), 0 deletions(-)
create mode 100644 include/cell-info.h
diff --git a/include/cell-info.h b/include/cell-info.h
new file mode 100644
index 0000000..2b75819
--- /dev/null
+++ b/include/cell-info.h
@@ -0,0 +1,128 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2009-2010 Nokia Corporation and/or its subsidiary(-ies).
+ *
+ * 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_CELL_INFO_H
+#define __OFONO_CELL_INFO_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include <ofono/types.h>
+#include <stdint.h>
+
+struct ofono_cell_info;
+
+
+#define OFONO_CI_FIELD_TA_UNDEFINED 0xFF
+#define OFONO_CI_FIELD_UCID_UNDEFINED 0xFFFFFFFF
+#define OFONO_CI_FIELD_ECN0_UNDEFINED 0xFF
+#define OFONO_CI_FIELD_RSCP_UNDEFINED -127
+#define OFONO_CI_FIELD_PATHLOSS_UNDEFINED 0xFF
+#define OFONO_CI_FIELD_FREQ_UNDEFINED 0xFFFF
+
+#define OFONO_MAX_NMR_COUNT 15
+#define OFONO_MAX_MEASURED_CELL_COUNT 32
+#define OFONO_MAX_MEAS_RES_LIST_COUNT 8
+
+enum ofono_cell_type {
+ OFONO_CELL_TYPE_GERAN,
+ OFONO_CELL_TYPE_UTRAN_FDD
+};
+
+struct geran {
+ uint16_t lac;
+ uint16_t ci;
+ uint8_t ta;
+ uint8_t no_cells;
+ struct geran_neigh_cell {
+ uint16_t arfcn;
+ uint8_t bsic;
+ uint8_t rxlev;
+ } nmr[OFONO_MAX_NMR_COUNT];
+};
+
+struct cell_measured_results {
+ uint32_t ucid;
+ uint16_t sc;
+ uint8_t ecn0;
+ int8_t rscp;
+ uint8_t pathloss;
+};
+
+struct measured_results_list {
+ uint16_t dl_freq;
+ uint16_t ul_freq;
+ uint8_t rssi;
+ uint8_t no_cells;
+ struct cell_measured_results cmr[OFONO_MAX_MEASURED_CELL_COUNT];
+};
+
+struct utran {
+ uint32_t ucid;
+ uint16_t dl_freq;
+ uint16_t ul_freq;
+ uint16_t sc;
+ uint8_t no_freq;
+ struct measured_results_list mrl[OFONO_MAX_MEAS_RES_LIST_COUNT];
+};
+
+struct ofono_cell_info_results {
+ enum ofono_cell_type rat;
+ uint16_t mcc;
+ uint16_t mnc;
+ union {
+ struct geran geran;
+ struct utran utran;
+ };
+};
+
+
+typedef void (*ofono_cell_info_query_cb_t)(const struct ofono_error *error,
+ struct ofono_cell_info_results *results, void *data);
+
+struct ofono_cell_info_driver {
+ const char *name;
+ int (*probe)(struct ofono_cell_info *ci,
+ unsigned int vendor,
+ void *data);
+ void (*remove)(struct ofono_cell_info *ci);
+ void (*query)(struct ofono_cell_info *ci,
+ ofono_cell_info_query_cb_t cb,
+ void *data);
+};
+
+struct ofono_cell_info *ofono_cell_info_create(struct ofono_modem *modem,
+ unsigned int vendor,
+ const char *driver,
+ void *data);
+
+void ofono_cell_info_register(struct ofono_cell_info *ci);
+void ofono_cell_info_remove(struct ofono_cell_info *ci);
+int ofono_cell_info_driver_register(struct ofono_cell_info_driver *driver);
+void ofono_cell_info_driver_unregister(struct ofono_cell_info_driver *driver);
+void *ofono_cell_info_get_data(struct ofono_cell_info *ci);
+void ofono_cell_info_set_data(struct ofono_cell_info *ci, void *cid);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __OFONO_CELL_INFO_H */
--
1.7.1
8:33 p.m.
New subject: [PATCH 1/5] cell-info: Header file for cell info atom
Hi Antti,
+struct ofono_cell_info_results {
+ enum ofono_cell_type rat;
+ uint16_t mcc;
+ uint16_t mnc;
+ union {
+ struct geran geran;
+ struct utran utran;
+ };
+};
Is there such a case that modem reports a GERAN serving cell info together with some UTRAN
neighbouring cell infos?
Regards,
Wei, Jun 韦峻
Email: jun.wei(a)intel.com
12:27 a.m.
New subject: [PATCH 2/5] cell-info: Atom for ECID info of neighb cells
---
src/cell-info.c | 512 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 512 insertions(+), 0 deletions(-)
create mode 100644 src/cell-info.c
diff --git a/src/cell-info.c b/src/cell-info.c
new file mode 100644
index 0000000..1a561e4
--- /dev/null
+++ b/src/cell-info.c
@@ -0,0 +1,512 @@
+/*
+ *
+ * oFono - Open Source Telephony
+ *
+ * Copyright (C) 2009-2010 Nokia Corporation and/or its subsidiary(-ies).
+ *
+ * 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
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <string.h>
+#include <stdio.h>
+#include <errno.h>
+
+#include <glib.h>
+#include <gdbus.h>
+#include <sys/time.h>
+
+#include "ofono.h"
+
+#include "common.h"
+#include "util.h"
+#include "ofono/cell-info.h"
+
+
+struct ofono_cell_info {
+ DBusMessage *pending;
+ struct ofono_atom *atom;
+ const struct ofono_cell_info_driver *driver;
+ void *driver_data;
+ gboolean incl_neigh;
+};
+
+
+static DBusMessage *ci_get_cells(DBusConnection *, DBusMessage *, void *);
+static DBusMessage *ci_get_properties(DBusConnection *, DBusMessage *, void *);
+
+static GSList *g_drivers = NULL;
+
+static GDBusMethodTable ci_methods[] = {
+ { "GetNeighborCellInfo", "", "a{sv}aa{sv}", ci_get_cells,
+ G_DBUS_METHOD_FLAG_ASYNC },
+ { "GetProperties", "", "a{sv}", ci_get_properties,
+ G_DBUS_METHOD_FLAG_ASYNC },
+
+ { }
+};
+
+static GDBusSignalTable ci_signals[] = {
+ { }
+};
+
+int ofono_cell_info_driver_register(struct ofono_cell_info_driver *driver)
+{
+ DBG("driver: %p, name: %s", driver, driver->name);
+
+ if (driver->probe == NULL)
+ return -EINVAL;
+
+ g_drivers = g_slist_prepend(g_drivers, (void *) driver);
+
+ return 0;
+}
+
+void ofono_cell_info_driver_unregister(struct ofono_cell_info_driver *driver)
+{
+ DBG("driver: %p, name: %s", driver, driver->name);
+
+ g_drivers = g_slist_remove(g_drivers, (void *) driver);
+}
+
+void ofono_cell_info_remove(struct ofono_cell_info *ci)
+{
+ __ofono_atom_free(ci->atom);
+}
+
+static void cell_info_unregister(struct ofono_atom *atom)
+{
+ struct ofono_cell_info *ci = __ofono_atom_get_data(atom);
+ const char *path = __ofono_atom_get_path(ci->atom);
+ DBusConnection *conn = ofono_dbus_get_connection();
+ struct ofono_modem *modem = __ofono_atom_get_modem(ci->atom);
+
+ ofono_modem_remove_interface(modem, OFONO_CELL_INFO_INTERFACE);
+
+ if (!g_dbus_unregister_interface(conn, path, OFONO_CELL_INFO_INTERFACE))
+ ofono_error("Failed to unregister interface %s",
+ OFONO_CELL_INFO_INTERFACE);
+}
+
+static void cell_info_remove(struct ofono_atom *atom)
+{
+ struct ofono_cell_info *ci = __ofono_atom_get_data(atom);
+ DBG("atom: %p", atom);
+
+ if (ci == NULL)
+ return;
+
+ if (ci->driver && ci->driver->remove)
+ ci->driver->remove(ci);
+
+ g_free(ci);
+}
+
+void ofono_cell_info_register(struct ofono_cell_info *ci)
+{
+ DBusConnection *conn = ofono_dbus_get_connection();
+ struct ofono_modem *modem = __ofono_atom_get_modem(ci->atom);
+ const char *path = __ofono_atom_get_path(ci->atom);
+
+ DBG("Modem: %p", modem);
+
+ if (!g_dbus_register_interface(conn, path,
+ OFONO_CELL_INFO_INTERFACE,
+ ci_methods, ci_signals, NULL,
+ ci, NULL)) {
+ ofono_error("Could not create %s interface",
+ OFONO_CELL_INFO_INTERFACE);
+
+ return;
+ }
+
+ ofono_modem_add_interface(modem, OFONO_CELL_INFO_INTERFACE);
+
+ __ofono_atom_register(ci->atom, cell_info_unregister);
+}
+
+struct ofono_cell_info *ofono_cell_info_create(struct ofono_modem *modem,
+ unsigned int vendor,
+ const char *driver,
+ void *data)
+{
+ struct ofono_cell_info *ci;
+ GSList *l;
+
+ if (driver == NULL)
+ return NULL;
+
+ ci = g_try_new0(struct ofono_cell_info, 1);
+ if (ci == NULL)
+ return NULL;
+
+ ci->atom = __ofono_modem_add_atom(modem,
+ OFONO_ATOM_TYPE_CELL_INFO,
+ cell_info_remove, ci);
+
+ for (l = g_drivers; l; l = l->next) {
+ const struct ofono_cell_info_driver *drv = l->data;
+
+ if (g_strcmp0(drv->name, driver))
+ continue;
+
+ if (drv->probe(ci, vendor, data) < 0)
+ continue;
+
+ ci->driver = drv;
+ break;
+ }
+
+ return ci;
+}
+
+void *ofono_cell_info_get_data(struct ofono_cell_info *ci)
+{
+ return ci->driver_data;
+}
+
+void ofono_cell_info_set_data(struct ofono_cell_info *ci, void *cid)
+{
+ ci->driver_data = cid;
+}
+
+static int append_geran_meta_data(DBusMessageIter *iter,
+ struct ofono_cell_info_results *ci)
+{
+ DBusMessageIter iter_array;
+ const char *type = "GERAN";
+
+ dbus_message_iter_open_container(iter,
+ DBUS_TYPE_ARRAY,
+ "{sv}",
+ &iter_array);
+
+ ofono_dbus_dict_append(&iter_array,
+ "Type",
+ DBUS_TYPE_STRING,
+ &type);
+ ofono_dbus_dict_append(&iter_array,
+ "MobileNetworkCode",
+ DBUS_TYPE_UINT16,
+ &ci->mnc);
+ ofono_dbus_dict_append(&iter_array,
+ "MobileCountryCode",
+ DBUS_TYPE_UINT16,
+ &ci->mcc);
+ ofono_dbus_dict_append(&iter_array,
+ "LocationAreaCode",
+ DBUS_TYPE_UINT16,
+ &ci->geran.lac);
+ ofono_dbus_dict_append(&iter_array,
+ "CellId",
+ DBUS_TYPE_UINT16,
+ &ci->geran.ci);
+
+ if (ci->geran.ta != 1)
+ ofono_dbus_dict_append(&iter_array,
+ "TimingAdvance",
+ DBUS_TYPE_BYTE,
+ &ci->geran.ta);
+
+ dbus_message_iter_close_container(iter, &iter_array);
+
+ return 0;
+
+}
+
+static void add_geran_neighbor(DBusMessageIter *iter,
+ struct geran_neigh_cell *cell)
+{
+ DBusMessageIter iter_array;
+
+ dbus_message_iter_open_container(iter,
+ DBUS_TYPE_ARRAY,
+ "{sv}",
+ &iter_array);
+ ofono_dbus_dict_append(&iter_array,
+ "AbsoluteRadioFrequencyChannelNumber",
+ DBUS_TYPE_UINT16,
+ &cell->arfcn);
+ ofono_dbus_dict_append(&iter_array,
+ "BaseStationIdentityCode",
+ DBUS_TYPE_BYTE,
+ &cell->bsic);
+ ofono_dbus_dict_append(&iter_array,
+ "RXLEV",
+ DBUS_TYPE_BYTE,
+ &cell->rxlev);
+
+ dbus_message_iter_close_container(iter, &iter_array);
+}
+
+static int fill_geran_ci(DBusMessage *msg,
+ struct ofono_cell_info_results *ci,
+ gboolean incl_neigh)
+{
+ DBusMessageIter iter, iter_array;
+ int i;
+
+ dbus_message_iter_init_append(msg, &iter);
+ append_geran_meta_data(&iter, ci);
+
+ if (!incl_neigh)
+ return 0;
+
+ dbus_message_iter_open_container(&iter,
+ DBUS_TYPE_ARRAY,
+ "a{sv}",
+ &iter_array);
+
+ for (i = 0; i < ci->geran.no_cells; ++i)
+ add_geran_neighbor(&iter_array, &ci->geran.nmr[i]);
+
+ dbus_message_iter_close_container(&iter, &iter_array);
+
+ return 0;
+}
+
+static int append_utra_neigh_cell_data(DBusMessageIter *iter,
+ struct cell_measured_results *cmr)
+{
+ ofono_dbus_dict_append(iter,
+ "ScramblingCode",
+ DBUS_TYPE_UINT16,
+ &cmr->sc);
+
+ if (cmr->ucid != OFONO_CI_FIELD_UCID_UNDEFINED)
+ ofono_dbus_dict_append(iter,
+ "UniqueCellId",
+ DBUS_TYPE_UINT32,
+ &cmr->ucid);
+
+ if (cmr->ecn0 != OFONO_CI_FIELD_ECN0_UNDEFINED)
+ ofono_dbus_dict_append(iter,
+ "CPICH-ECN0",
+ DBUS_TYPE_BYTE,
+ &cmr->ecn0);
+
+ if (cmr->rscp != OFONO_CI_FIELD_RSCP_UNDEFINED)
+ ofono_dbus_dict_append(iter,
+ "CPICH-RSCP",
+ DBUS_TYPE_INT16,
+ &cmr->rscp);
+
+ if (cmr->pathloss != OFONO_CI_FIELD_PATHLOSS_UNDEFINED)
+ ofono_dbus_dict_append(iter,
+ "Pathloss",
+ DBUS_TYPE_BYTE,
+ &cmr->pathloss);
+
+ return 0;
+}
+
+static int append_utra_neigh_freq_data(DBusMessageIter *iter,
+ struct measured_results_list *mrl)
+{
+ ofono_dbus_dict_append(iter,
+ "ReceivedSignalStrengthIndicator",
+ DBUS_TYPE_BYTE,
+ &mrl->rssi);
+
+ ofono_dbus_dict_append(iter,
+ "UARFCN-DL",
+ DBUS_TYPE_UINT16,
+ &mrl->dl_freq);
+
+ if (mrl->ul_freq != OFONO_CI_FIELD_FREQ_UNDEFINED)
+ ofono_dbus_dict_append(iter,
+ "UARFCN-UL",
+ DBUS_TYPE_UINT16,
+ &mrl->ul_freq);
+
+ return 0;
+}
+
+static int append_utra_neighbors(DBusMessageIter *iter,
+ struct utran *utran)
+{
+ DBusMessageIter iter_array, iter_array_array;
+ int i, j;
+
+ dbus_message_iter_open_container(iter,
+ DBUS_TYPE_ARRAY,
+ "a{sv}",
+ &iter_array);
+
+ for (i = 0; i < utran->no_freq; ++i) {
+
+ for (j = 0; j < utran->mrl[i].no_cells; ++j) {
+ dbus_message_iter_open_container(&iter_array,
+ DBUS_TYPE_ARRAY,
+ "{sv}",
+ &iter_array_array);
+ append_utra_neigh_freq_data(&iter_array_array,
+ &utran->mrl[i]);
+ append_utra_neigh_cell_data(&iter_array_array,
+ &utran->mrl[i].cmr[j]);
+
+ dbus_message_iter_close_container(&iter_array,
+ &iter_array_array);
+ }
+ }
+
+ dbus_message_iter_close_container(iter, &iter_array);
+
+ return 0;
+}
+
+static void append_utran_meta_data(DBusMessageIter *iter,
+ struct ofono_cell_info_results *ci)
+{
+ DBusMessageIter iter_array;
+ const char *type = "UTRA-FDD";
+
+ dbus_message_iter_open_container(iter,
+ DBUS_TYPE_ARRAY,
+ "{sv}",
+ &iter_array);
+
+ ofono_dbus_dict_append(&iter_array,
+ "Type",
+ DBUS_TYPE_STRING,
+ &type);
+ ofono_dbus_dict_append(&iter_array,
+ "MobileNetworkCode",
+ DBUS_TYPE_UINT16,
+ &ci->mnc);
+ ofono_dbus_dict_append(&iter_array,
+ "MobileCountryCode",
+ DBUS_TYPE_UINT16,
+ &ci->mcc);
+ ofono_dbus_dict_append(&iter_array,
+ "UniqueCellId",
+ DBUS_TYPE_UINT32,
+ &ci->utran.ucid);
+ ofono_dbus_dict_append(&iter_array,
+ "ScramblingCode",
+ DBUS_TYPE_UINT16,
+ &ci->utran.sc);
+ ofono_dbus_dict_append(&iter_array,
+ "UARFCN-DL",
+ DBUS_TYPE_UINT16,
+ &ci->utran.dl_freq);
+
+ if (ci->utran.ul_freq != OFONO_CI_FIELD_FREQ_UNDEFINED) {
+ ofono_dbus_dict_append(&iter_array,
+ "UARFCN-UL",
+ DBUS_TYPE_UINT16,
+ &ci->utran.ul_freq);
+ }
+
+ dbus_message_iter_close_container(iter, &iter_array);
+}
+
+static int fill_utra_ci(DBusMessage *msg,
+ struct ofono_cell_info_results *ci,
+ gboolean incl_neigh)
+{
+ DBusMessageIter iter;
+
+ dbus_message_iter_init_append(msg, &iter);
+ append_utran_meta_data(&iter, ci);
+
+ if (incl_neigh)
+ append_utra_neighbors(&iter, &ci->utran);
+
+ return 0;
+}
+
+static void ofono_neigh_cell_info_query_cb(const struct ofono_error *error,
+ struct ofono_cell_info_results *ci_results, void *data)
+{
+ struct ofono_cell_info *ci = data;
+ DBusMessage *msg = ci->pending;
+ DBusMessage *reply;
+ int status;
+
+ DBG("");
+
+ if (error->type != OFONO_ERROR_TYPE_NO_ERROR) {
+ ofono_error("Neighbor cell info query failed");
+ goto error;
+ }
+
+ reply = dbus_message_new_method_return(msg);
+ if (reply == NULL) {
+ ofono_error("Failed to create response");
+ goto error;
+ }
+
+ if (ci_results->rat == OFONO_CELL_TYPE_GERAN) {
+ ofono_debug("GERAN CELL INFO RECEIVED");
+
+ status = fill_geran_ci(reply, ci_results, ci->incl_neigh);
+ if (status != 0) {
+ ofono_error("Failed to fill geran info");
+ goto error;
+ }
+
+ } else if (ci_results->rat == OFONO_CELL_TYPE_UTRAN_FDD) {
+ ofono_debug("UTRAN CELL INFO RECEIVED");
+
+ status = fill_utra_ci(reply, ci_results, ci->incl_neigh);
+ if (status != 0) {
+ ofono_error("Failed to fill utran info");
+ goto error;
+ }
+
+ } else {
+ ofono_error("Unrecognized cell type.");
+ goto error;
+ }
+
+ __ofono_dbus_pending_reply(&msg, reply);
+ return;
+
+error:
+ reply = __ofono_error_failed(msg);
+ __ofono_dbus_pending_reply(&msg, reply);
+ return;
+
+}
+
+static DBusMessage *ci_get_cells(DBusConnection *conn, DBusMessage *msg,
+ void *data)
+{
+ struct ofono_cell_info *ci = data;
+ DBG("");
+
+ ci->incl_neigh = TRUE;
+ ci->pending = dbus_message_ref(msg);
+ ci->driver->query(ci, ofono_neigh_cell_info_query_cb, ci->driver_data);
+
+ return NULL;
+}
+
+static DBusMessage *ci_get_properties(DBusConnection *conn, DBusMessage *msg,
+ void *data)
+{
+ struct ofono_cell_info *ci = data;
+ DBG("");
+
+ ci->incl_neigh = FALSE;
+ ci->pending = dbus_message_ref(msg);
+ ci->driver->query(ci, ofono_neigh_cell_info_query_cb, ci->driver_data);
+
+ return NULL;
+}
--
1.7.1
12:27 a.m.
New subject: [PATCH 3/5] cell-info: Interface declaration for cell info
---
include/dbus.h | 1 +
src/ofono.h | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/dbus.h b/include/dbus.h
index c527515..98839cc 100644
--- a/include/dbus.h
+++ b/include/dbus.h
@@ -45,6 +45,7 @@ extern "C" {
#define OFONO_MESSAGE_WAITING_INTERFACE "org.ofono.MessageWaiting"
#define OFONO_NETWORK_REGISTRATION_INTERFACE "org.ofono.NetworkRegistration"
#define OFONO_NETWORK_OPERATOR_INTERFACE "org.ofono.NetworkOperator"
+#define OFONO_CELL_INFO_INTERFACE "org.ofono.CellInfo"
#define OFONO_PHONEBOOK_INTERFACE "org.ofono.Phonebook"
#define OFONO_RADIO_SETTINGS_INTERFACE "org.ofono.RadioSettings"
#define OFONO_AUDIO_SETTINGS_INTERFACE "org.ofono.AudioSettings"
diff --git a/src/ofono.h b/src/ofono.h
index cab70cd..820e3a3 100644
--- a/src/ofono.h
+++ b/src/ofono.h
@@ -127,6 +127,7 @@ enum ofono_atom_type {
OFONO_ATOM_TYPE_NETTIME = 21,
OFONO_ATOM_TYPE_CTM = 22,
OFONO_ATOM_TYPE_CDMA_VOICECALL_MANAGER = 23,
+ OFONO_ATOM_TYPE_CELL_INFO = 24,
};
enum ofono_atom_watch_condition {
--
1.7.1
12:27 a.m.
New subject: [PATCH 4/5] cell-info: New files included for compilation
---
Makefile.am | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index dfdb7bd..d9b0ad3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,7 +14,8 @@ include_HEADERS = include/log.h include/plugin.h include/history.h \
include/gprs.h include/gprs-context.h \
include/radio-settings.h include/stk.h \
include/audio-settings.h include/nettime.h \
- include/ctm.h include/cdma-voicecall.h
+ include/ctm.h include/cdma-voicecall.h \
+ include/cell-info.h
nodist_include_HEADERS = include/version.h
@@ -328,7 +329,7 @@ src_ofonod_SOURCES = $(gdbus_sources) $(builtin_sources) src/ofono.ver
\
src/nettime.c src/stkagent.c src/stkagent.h \
src/simfs.c src/simfs.h src/audio-settings.c \
src/smsagent.c src/smsagent.h src/ctm.c \
- src/cdma-voicecall.c
+ src/cdma-voicecall.c src/cell-info.c
src_ofonod_LDADD = $(builtin_libadd) @GLIB_LIBS@ @DBUS_LIBS@ @CAPNG_LIBS@ -ldl
@@ -367,7 +368,8 @@ doc_files = doc/overview.txt doc/ofono-paper.txt doc/release-faq.txt
\
doc/message-api.txt doc/message-waiting-api.txt \
doc/phonebook-api.txt doc/radio-settings-api.txt \
doc/sim-api.txt doc/stk-api.txt \
- doc/audio-settings-api.txt doc/text-telephony-api.txt
+ doc/audio-settings-api.txt doc/text-telephony-api.txt \
+ doc/cell-info.txt
test_scripts = test/backtrace \
--
1.7.1
12:27 a.m.
New subject: [PATCH 5/5] cell-info: Documentation
---
doc/cell-info.txt | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 doc/cell-info.txt
diff --git a/doc/cell-info.txt b/doc/cell-info.txt
new file mode 100644
index 0000000..b288e69
--- /dev/null
+++ b/doc/cell-info.txt
@@ -0,0 +1,124 @@
+Cell Info hierarchy
+===================
+
+Service org.ofono
+Interface org.ofono.CellInfo
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods a{sv}aa{sv} GetNeighborCellInfo()
+
+ Calling this procedure returns properties of serving
+ and neighbouring cells in GSM or WCDMA networks. This
+ information can be used to determine current location
+ using triangulation over neighbouring cell tower
+ locations and estimated distances.
+
+ The return value consists of two parts: 1) dictionary
+ of common information about network and serving cell 2)
+ array of dictionaries containing measurement results
+ of neighbouring cells. The contents of the dictionaries
+ follow the specification OMA-TS-ULP-V2_0-20100816-C for
+ user plane Location and is described in properties
+ section.
+
+ a{sv} GetProperties
+
+ Calling this procedure returns properties of serving
+ cell in GSM or WCDMA networks. Effectively the data
+ returned is the part 1 of the data returned by
+ GetNeighborCellInfo.
+
+Properties
+
+a{sv] string Type
+
+ Radio access network type of neighbor cell information.
+
+ The possible values are:
+ "geran" Measurement results are for the GSM EDGE Radio
+ Access Network.
+ "utran" Measurement results are for UMTS Radio Access
+ Network.
+
+ uint16 MobileCountryCode
+ Mobile Country Code of serving cell. Possible values:
+ Values: 0...999"
+
+ uint16 MobileNetworkCode
+ Mobile Network Code of serving cell.
+ Values: 0...999"
+
+ uint16 LocationAreaCode [GERAN]
+ Location area code of serving cell.
+ Values: 0...65535
+
+ uint16 CellId [GERAN]
+ Cell Id of serving cell.
+ Values: 0...65535
+
+ byte TimingAdvance [GERAN, optional]
+ Timing advance.
+ Values: 0...63
+
+ uint32 UniqueCellId [UTRA-FDD]
+ Serving WCDMA unique cell ID.
+ Values: 0...268435455
+
+ uint16 ScramblingCode [UTRA-FDD]
+ Primary scrambling code.
+ Values: 0...511
+
+ uint16 UARFCN-DL [UTRA-FDD]
+ Downlink UTRA Absolute Radio Frequency Channel Number
+ of serving cell.
+ Values: 0...16383
+
+ uint16 UARFCN-UL [UTRA-FDD, optional]
+ Uplink UTRA Absolute Radio Frequency Channel Number.
+ Values: 0...16383
+
+
+aa{sv} uint16 AbsoluteRadioFrequencyChannelNumber [GERAN]
+ Absolute radio frequency channel number.
+ Values: 0...1023
+
+ byte BaseStationIdentityCode [GERAN]
+ Base station identity code.
+ Values: 0...63.
+
+ byte RXLEV [GERAN]
+ Measured power of the channel.
+ Values: 0...63
+
+ byte ReceivedSignalStrengthIndicator [UTRA-FDD]
+ RX power level.
+ Values: 0...127
+
+ uint16 UARFCN-DL [UTRA-FDD]
+ Downlink UARFCN.
+ Values: 0...16383
+
+ uint16 UARFCN-UL [UTRA-FDD, optional]
+ Uplink UARFCN.
+ Values: 0...16383
+
+ uint16 ScramblingCode [UTRA-FDD]
+ Primary scrambling code.
+ Values: 0...511
+
+ uint32 UniqueCellId [UTRA-FDD, optional]
+ Unique cell ID.
+ Values: 0...268435455
+
+ byte CPICH-ECN0 [UTRA-FDD, optional]
+ Common pilot channel RX energy per chip over noise
+ density in dB.
+ Values: 0...63
+
+ int16 CPICH-RSCP [UTRA-FDD, optional]
+ Common pilot channel RX carrier power in dBm
+ Values: -4...127
+
+ byte Pathloss [UTRA-FDD, optional]
+ Measured path loss in dB.
+ Values: 46...173
--
1.7.1
4:13 a.m.
New subject: [PATCH 5/5] cell-info: Documentation
Hi Antti,
doc/cell-info.txt | 124
+++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 124 insertions(+), 0 deletions(-)
create mode 100644 doc/cell-info.txt
diff --git a/doc/cell-info.txt b/doc/cell-info.txt
new file mode 100644
index 0000000..b288e69
--- /dev/null
+++ b/doc/cell-info.txt
@@ -0,0 +1,124 @@
+Cell Info hierarchy
+===================
+
+Service org.ofono
+Interface org.ofono.CellInfo
+Object path [variable prefix]/{modem0,modem1,...}
+
+Methods a{sv}aa{sv} GetNeighborCellInfo()
+
+ Calling this procedure returns properties of serving
+ and neighbouring cells in GSM or WCDMA networks. This
+ information can be used to determine current location
+ using triangulation over neighbouring cell tower
+ locations and estimated distances.
+
+ The return value consists of two parts: 1) dictionary
+ of common information about network and serving cell 2)
+ array of dictionaries containing measurement results
+ of neighbouring cells. The contents of the dictionaries
+ follow the specification OMA-TS-ULP-V2_0-20100816-C for
+ user plane Location and is described in properties
+ section.
+
+ a{sv} GetProperties
+
+ Calling this procedure returns properties of serving
+ cell in GSM or WCDMA networks. Effectively the data
+ returned is the part 1 of the data returned by
+ GetNeighborCellInfo.
why do we bother here with two methods calls. What is the use of getting
only half of the information. You are making the same call to the
hardware, so why not return the same information.
The method name org.ofono.CellInfo.GetNeighborCellInfo is also not
really good. I duplicates the CellInfo information. So I would just have
called this GetNeighbors.
What is the reason behind a{sv}aa{sv} here? Wouldn't it be simpler to
just go with aa{sv} and declare that the first dict is always the
current serving cell? Are the information from the current cell really
that different than from the neighbors?
One other think that I don't really like with the GetProperties part is
that we could expect a PropertiesChanged signal. However that is not
really going to happen since the query should only be done on demand. So
I would prefer if we then don't have properties at all in this case.
Regards
Marcel
6:18 p.m.
New subject: [PATCH 5/5] cell-info: Documentation
Hi Marcel,
On Tue, 2010-12-28 at 09:13 -0800, ext Marcel Holtmann wrote:
Hi Antti,
> doc/cell-info.txt | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 124 insertions(+), 0 deletions(-)
> create mode 100644 doc/cell-info.txt
>
> diff --git a/doc/cell-info.txt b/doc/cell-info.txt
> new file mode 100644
> index 0000000..b288e69
> --- /dev/null
> +++ b/doc/cell-info.txt
> @@ -0,0 +1,124 @@
> +Cell Info hierarchy
> +===================
> +
> +Service org.ofono
> +Interface org.ofono.CellInfo
> +Object path [variable prefix]/{modem0,modem1,...}
> +
> +Methods a{sv}aa{sv} GetNeighborCellInfo()
> +
> + Calling this procedure returns properties of serving
> + and neighbouring cells in GSM or WCDMA networks. This
> + information can be used to determine current location
> + using triangulation over neighbouring cell tower
> + locations and estimated distances.
> +
> + The return value consists of two parts: 1) dictionary
> + of common information about network and serving cell 2)
> + array of dictionaries containing measurement results
> + of neighbouring cells. The contents of the dictionaries
> + follow the specification OMA-TS-ULP-V2_0-20100816-C for
> + user plane Location and is described in properties
> + section.
> +
> + a{sv} GetProperties
> +
> + Calling this procedure returns properties of serving
> + cell in GSM or WCDMA networks. Effectively the data
> + returned is the part 1 of the data returned by
> + GetNeighborCellInfo.
why do we bother here with two methods calls. What is the use of getting
only half of the information. You are making the same call to the
hardware, so why not return the same information.
The GetProperties was kind of last minute glue-on but it was not without
a reason. This atom is about cell info and hence I implicitly assumed
that when you want to query the properties of a cell you would mean the
cell that is your current serving cell. Since nearly all atoms have
GetProperties method, this would be in line with oFono conventions and
services that assume that interface has GetProperties -method could
utilize the cell info. As an example, 'list-modems'-script would nicely
print the serving cell info for a modem.
If the client wants the measurement result of neighboring cells, it
needs to call the GetNeighbors method explicitly. Even if internally
these two methods lead to same hardware call, I don't believe this
should effect the design of DBUS interface, that is visible to client
applications.
That was the reasoning behind the decision to include GetProperties
-method. If you still believe it is not right I can remove the method.
The method name org.ofono.CellInfo.GetNeighborCellInfo is also not
really good. I duplicates the CellInfo information. So I would just have
called this GetNeighbors.
I agree about the naming. GetNeighbors is better.
What is the reason behind a{sv}aa{sv} here? Wouldn't it be
simpler to
just go with aa{sv} and declare that the first dict is always the
current serving cell? Are the information from the current cell really
that different than from the neighbors?
The rationale is that this is the format OMA-TS-ULP-V2_0-20100816-C and
3GPP RRC define for user plane location. Also, all modems don't provide
the same information for serving and neighbor cells; e.g. isimodem
follows the above mentioned specs. I believe that for location purposes
the information included in the a{sv} part is not needed for neighbors.
Hence making the structure flat would not really make things simpler.
One other think that I don't really like with the GetProperties
part is
that we could expect a PropertiesChanged signal. However that is not
really going to happen since the query should only be done on demand. So
I would prefer if we then don't have properties at all in this case.
Agreed. Yet again, this is about interface design and what services we
want to provide for clients. I am not religiously trying to defend my
approach, but merely opening the reasons behind the implementation.
Thanks for the comments.
Best Regards,
Antti
9:39 p.m.
New subject: [PATCH 5/5] cell-info: Documentation
Hi Antti,
2010/12/29 Antti Paila <antti.paila(a)nokia.com>:
The GetProperties was kind of last minute glue-on but it was not
without
a reason. This atom is about cell info and hence I implicitly assumed
that when you want to query the properties of a cell you would mean the
cell that is your current serving cell. Since nearly all atoms have
GetProperties method, this would be in line with oFono conventions and
services that assume that interface has GetProperties -method could
utilize the cell info. As an example, 'list-modems'-script would nicely
print the serving cell info for a modem.
I agree with Marcel here. A GetProperties is not necessary here,
especially since the backend is still the same poll-only interface
which means there won't be a PropertyChanged ever.
Also, the list-modems script is a weak argument. It is trivial to
change to make it call the GetNeighbors method. Let's not forget the
use case this is trying to solve, which is positioning engine
requesting nmr data. Likely other clients that need cell info are
mostly going to follow NetworkRegistration and its LAC and CI
properties.
If the client wants the measurement result of neighboring cells, it
needs to call the GetNeighbors method explicitly. Even if internally
these two methods lead to same hardware call, I don't believe this
should effect the design of DBUS interface, that is visible to client
applications.
That was the reasoning behind the decision to include GetProperties
-method. If you still believe it is not right I can remove the method.
Yeah, I'd say take it out.
> What is the reason behind a{sv}aa{sv} here? Wouldn't it be
simpler to
> just go with aa{sv} and declare that the first dict is always the
> current serving cell? Are the information from the current cell really
> that different than from the neighbors?
The rationale is that this is the format OMA-TS-ULP-V2_0-20100816-C and
3GPP RRC define for user plane location. Also, all modems don't provide
the same information for serving and neighbor cells; e.g. isimodem
follows the above mentioned specs. I believe that for location purposes
the information included in the a{sv} part is not needed for neighbors.
Hence making the structure flat would not really make things simpler.
I originally suggested a{sv}aa{sv}, but I don't see a problem this
being just a flat aa{sv}. The keys in dicts can always be different,
and if the documentation clearly states that the first dict is always
meta-data, followed by the actual neighbor measurements, it'll work
just the same.
Cheers,
Aki
7:42 a.m.
New subject: [PATCH 5/5] cell-info: Documentation
Hi Aki,
>> What is the reason behind a{sv}aa{sv} here? Wouldn't it
be simpler to
>> just go with aa{sv} and declare that the first dict is always the
>> current serving cell? Are the information from the current cell really
>> that different than from the neighbors?
>
> The rationale is that this is the format OMA-TS-ULP-V2_0-20100816-C and
> 3GPP RRC define for user plane location. Also, all modems don't provide
> the same information for serving and neighbor cells; e.g. isimodem
> follows the above mentioned specs. I believe that for location purposes
> the information included in the a{sv} part is not needed for neighbors.
> Hence making the structure flat would not really make things simpler.
I originally suggested a{sv}aa{sv}, but I don't see a problem this
being just a flat aa{sv}. The keys in dicts can always be different,
and if the documentation clearly states that the first dict is always
meta-data, followed by the actual neighbor measurements, it'll work
just the same.
so the position engine would need the details that you provide in the
current serving cell. And just following network registration is not
good enough here?
Also the information from the current serving cell are really different
from the neighbor cell information?
Regards
Marcel
4276
days inactive
4282
days old
10 comments
4 participants
participants (4)
-
Aki Niemi -
Antti Paila -
Marcel Holtmann -
Wei, Jun