RE: ACTION-16 for SystemInfo API

I think "CELL" would work (though I would prefer "PLMN"). The key reason for knowing the network technology type in the past was to determine QoS characteristics, so services could be adapted e.g. to the available bandwidth.

Overall, the essential information is:

1) to which network(s) is the device *connected* (i.e. with an active data connection), with at least distinction between public (PLMN, WiMAX) and private (WiFi) wireless networks. For PLMN, MCC/MNC are adequate; for WiFi, SSID. I don't how WiMAX networks are identified.

2) roaming (however determined, at the levels of national and international). Note you can be registered to a PLMN (even roaming) and connected to WiFi. So these are two distinct properties.

3) QoS info (at least uplink/downlink bandwidth)

On the approach to supporting the current/preferred/available - either should work. But are you implying that if we created a specific interface for these, they would not be accessible via SystemInfo? I think that SystemInfo can act as a common shim layer for all the specific interfaces in the spec, thus the webapp developer should be able to use it exclusively.

Thanks, 
Bryan Sullivan | AT&T
-----Original Message-----
From: Max Froumentin [mailto:maxfro@opera.com] 
Sent: Monday, March 01, 2010 7:37 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: public-device-apis@w3.org; public-uwa@w3.org
Subject: Re: ACTION-16 for SystemInfo API

On 01/03/2010 13:22, SULLIVAN, BRYAN L (ATTCINW) wrote:

> LTE reference: http://www.3gpp.org/article/lte Long Term Evolution
> (LTE) focuses on enhancing the Universal Terrestrial Radio Access
> (UTRA) and optimizing 3GPP’s radio access architecture, with targets
> to have average user throughput of three- to four-times the Release 6
> HSDPA levels in the Downlink (100Mbps), and two to three times the
> HSUPA levels in the Uplink (50Mbps).

The list of connection types is becoming uncomfortably long, and new 
types seems to appear every other day. What do you think about the 
Issue, noted in the draft: "Should we gather all of GSM, GPRS, EDGE, 
CDMA, TETRA, UMTS under a singe "CELL" type? They could be 
differentiated by maxBandwidth, if needed."

> More network info (available, supported, default, and preferred) will
> help applications determine when a network can/should be used, or to
> provide clear guidance to the user as needed (e.g. "Your device
> supports WiFi. This app will work better if you set your default
> connection to WiFi.") If we take the approach that these are
> properties that can be returned through the SystemInfo interface
> (rather than creating specific interfaces for them), then there
> should be no additional spec effort to include them. Certainly the
> "active" network is good to include at least if we are creating
> specific interfaces.

There are many ways of doing this:

device.sysinfo.get("CurrentNetwork")
device.sysinfo.get("PreferredNetwork")
device.sysinfo.get("AvailableNetworks") <-- returns an array of Network 
objects, unless you provide an "id", letting you select a specific one 
(for watching)

Some time ago we had the following in the draft:

interface Network
{
   interface NetworkDevice currentNetwork;
   interface NetworkDevice preferredNetwork;
   interface NetworkDevice availableNetworks[];
}

I think that's better, because it's more in line with the rest of the 
specification (Storage, in particular).

But first we should decide if we have consensus on having the 3 items 
back. Then we can talk about what form it would have. A good topic for 
the Prague meeting, methinks.

Max.

Received on Monday, 1 March 2010 16:29:42 UTC