Network Context

The user's device connectivity is an important element of the context for receiving or sending an AR experience (or any content) to a remote resource.

Bandwidth
The first element of the network context is the bandwidth.

- how much bandwidth

- persistence of the bandwidth/coverage

- anticipated disruption in coverage/network connectivity

- cost of network connectivity

Network Information API
This is the memo sent to the AR Discovery mailing list on Oct 14.

In the e-mail below Bryan Sullivan (AT&T) mentions “current context” multiple times.

His bullets contain information we need to fill in the turquoise triangle in my figure on current context: the Network context (data plan, roaming status, the relationship between the service providers and any toll free data arrangements).

Bryan points out that it would be important to know the type of network connection in use. Key: The W3C Network Interface API.

Begin forwarded message:

 Resent-From:  public-web-mobile@w3.org

From:  "SULLIVAN, BRYAN L" 

Subject: RE: [W3C WebMob] Data Info API

Date: October 14, 2014 at 7:04:01 AM GMT+2

To: "'Natasha Rooney'" , W3C Webmob Public 

Hi Natasha,

Some quick comments. I’ll send it around also for more.

This is something that the GSMA Personal Data program could consider as part of the OneAPI Exchange program, e.g. enabled by Mobile Connect as the basic OpenID Connect based framework through which a personal data scoped query can be made into the subscriber’s data plan. But that would IMO be the easy part…

Such an API would likely not rely upon header injection for authentication, as that anachronistic approach would not work anyway for secure API’s (which this would certainly be). Authentication methods can be out of scope/orthogonal, e.g. as in OpenID Connect and Mobile Connect.

<p class="p5" style="font-size:14.4444446563721px;">But more importantly…

<p class="p5" style="font-size:14.4444446563721px;">·         Even with knowledge about the data plan, it’s still not so simple to assess the impact of any particular service as that depends upon the context and the service itself. Context can include e.g. roaming status and the relationship if any of the service providers or referenced resources to “toll free data” arrangements.

<p class="p5" style="font-size:14.4444446563721px;">·         Displaying this information to the user may not be all that helpful also, if the user is expected to make some decision given current context. The meaning of the information would need to be explained carefully, and still there would likely be misunderstanding. Clearly tech-savvy road-warrior types would be able to understand, but do we really want to add such decision burdens to the average user?

<p class="p5" style="font-size:14.4444446563721px;">·         Finally, knowing what type of network connection would ultimately be used for a service would be essential to really making this useful. We have tried for a long time to get browser vendors to support this info (e.g. simply the type of attached network, or a “WiFi” boolean) e.g. through the Network Information API, to no avail. This despite the info being easily available from device platforms, and simple to understand in terms of value to developers. Further, letting an app choose the type of network connection that should be used for a service/XHR/websocket/etc would be the real nirvana, but is even less likely.

<p class="p5" style="font-size:14.4444446563721px;">I would suggest that W3C revisit the Network Information API and add the features above, before we give additional information to apps through other network APIs, especially information that leaves the developer still unsure of the impact in the current context, or without options to change the current context programmatically.

<p class="p6" style="font-size:14.4444446563721px;">Thanks,

<p class="p6" style="font-size:14.4444446563721px;">Bryan Sullivan | Service Standards | AT&T

<p class="p7" style="font-size:14.4444446563721px;">From: Natasha Rooney

<p class="p7" style="font-size:14.4444446563721px;">Sent: Monday, October 13, 2014 8:26 PM

<p class="p7" style="font-size:14.4444446563721px;">To: W3C Webmob Public

<p class="p7" style="font-size:14.4444446563721px;">Subject: [W3C WebMob] Data Info API

<p class="p8" style="font-size:14.4444446563721px;"> Hi team!

<p class="p9" style="font-size:14.4444446563721px;"> I wanted to let you know that a few people from Mozilla, Google and Marcos and I have been chatting about a possible Data Info API. The API would return information about a user’s network data plan – this can then be used within the app to (for example) serve content which serves up less resources or maybe display the network status to the user so they don’t start watching a high-def movie on the train! We imagine there could be even more uses for this API, including using the API within web-based platforms to display details of the user’s plan directly to the user.

<p class="p9" style="font-size:14.4444446563721px;">I have spoken with some operators directly on this, and thanks to those who have given a great response on this so far! I would like all members of the group to take a look at the API rough plan (attached) and let us know what you think. If you’re a telecomms company member (and especially an operator) and you’d like to be involved in building or testing this, definitely get involved soon!

<p class="p9" style="font-size:14.4444446563721px;"> Thanks everyone!

<p class="p9" style="font-size:14.4444446563721px;">Natasha