W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2012

Re: Network Information Use Cases

From: Daniel Park <soohongp@gmail.com>
Date: Fri, 6 Jul 2012 10:55:00 +0900
Message-ID: <CAHSr+v1W-KROaKOsjwkNYwVVjcr5RaLF1x8dn+mzsokzx79KJw@mail.gmail.com>
To: Josh Soref <jsoref@rim.com>
Cc: Core Mobile <public-coremob@w3.org>, DAP <public-device-apis@w3.org>
(Sorry if I repeat something that already discussed in this thread...)

To me, most popular use cases of *network information* are

- smooth handover among various network interfaces on the mobile
devices: for instance, in case any of network interface is being
disconnected, app should be preparing the handover (depends user
setting for handover time such as jitter > 1sec, packet loss > 10%,
etc...) to another available interface where API should get these
available network information (enabled network interfaces and their
available bandwidth and features)...In this use case, *network
information API* is very useful...

- adaptive streaming according to network conditions: given the
*network information* API, app can obtain the network characteristics
especially available bandwidth, and piggyback to the contents servers
to adjust its ongoing traffics volumes. It is also very useful feature
for WebRTC where RTCWeb protocol (RTP or RTCP) is able to be used for
the signalling to piggyback the network information to the server
side.

- multihoming use case: in case the mobile node can use multiple
network interfaces (most case is both cellular and WiFi), app is able
to handle its communication style, for instance; watching the movie
through WiFi interface and paying something through cellular according
to network security level information via API. In addition, load
balancing between WiFi and cellular interfaces according to network
price information (cellular is 5G/Month and WiFi is free, etc) via API
is feasible, so that app can switch its ongoing services to WiFi from
cellular in order to prevent user's cellular overloading (over 5G
could be very expensive to user regardless of user intention).

These are very straightforward, but my point is to emphasize the value
of network information API...


Regards, Daniel


On Thu, Jul 5, 2012 at 5:31 AM, Josh Soref <jsoref@rim.com> wrote:
> Jean Francois Moy <jeanfrancois.moy@orange.com> wrote:
>> Sent: Wednesday, July 04, 2012 10:45 AM
>> To: public-coremob@w3.org
>> Subject: Network Information Use Cases
>>
>> Hello everyone,
>>
>> I had been assigned an action point that consists of describing use cases that
>> would encourage the inclusion of the Network Information APIs
>> <http://www.w3.org/TR/netinfo-api/>  in the Core Mobile level 1 specification.
>
> Thanks for the information.
>
>> I will list a few below:
>> *         Visual Voicemail platforms: Visual voicemail platforms are commonly
>> accessible only through 3G (platform access is restricted from the Internet).
>> The NetworkInformation APIs are required to detect the current interface, and
>> switch to 3G if a voicemail needs to be fetched. The Orange OMTP platforms
>> notably work like that.
>
> This is a bug in the platforms (or you could call it a "missing feature"). Switching the general connection could break a streaming video or other active links. The correct thing to do is for Orange (and friends) to add proper authentication for their platform so that it can deliver a token to the application which it can then use while it isn't on Cellular.
>
> Google Mail / Google Voice are able to do this (SMS 2FA / Application tokens).
>
>> *         TV Services: TV services and streams are secured and encrypted and use
>> the SIM and 3G network  for the authentication process. After the
>> authentication has been performed, it is possible to offload through the Wi-Fi
>> connection.
>
> This is a horrible abuse of 3G. It sounds like you want access to the Secure Element (SE). That's either in scope for the new Crypto WG, for NFC (but hopefully not) which might be abused for SE access, or Sys Apps.
>
>> *         Usage Applications: Most carriers provide applications that give real time
>> minutes and data usage for a user, as well as the possibility to
>> subscribe/unsubscribe to/from various options. Servers storing these
>> information can only be accessed through 3G access.
>
> This is a bug (Like the first). I can subscribe/unsubscribe to services by calling Wind Mobile (Canada) from a land line and giving them sufficient information to authenticate me. I shouldn't have to use your 3G network to check status. If I'm outside of your coverage zone ("roaming", e.g. to Japan), why shouldn't I be able to use WiFi to check used minutes?
>
>> As you see, it is important for carriers to know the current network, mostly for
>> authentication purposes, but also as some of our platforms are not accessible
>> from the Internet. It would also be nice to be capable of routing a connection
>> through an interface, but that's another story.
>
> Authentication purposes are not a remotely valid use case. Send an SMS to the device, let the user use that to answer a challenge. It works for Google, it works for Facebook. There's also SMS push or something which Bryan is asking for. That would actually be a more acceptable path forward than abusing Network Information.
>
> Please note that you don't need network information to find out if you're on cellular for these use cases, your local dns address will tell you, and the act of talking to the server is sufficient to tell you to go away.
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
>



-- 
Soohong Daniel Park
Samsung Electronics, SWC
Received on Friday, 6 July 2012 01:55:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 6 July 2012 01:55:29 GMT