Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WebMobileConnection

14 views
Skip to first unread message

Philipp von Weitershausen

unread,
Feb 27, 2012, 11:57:02 PM2/27/12
to dev-w...@lists.mozilla.org
Something that came out of the B2G work week last week: certain
(privileged) content should be able to find out information about the
device's mobile connection (relevant to both voice and data service),
e.g. whether there's service at all, what the signal strength is, etc.
One obvious use case for this is the status bar typically shown at the
top of mobile phone UIs.

I have compiled a proposal in WebIDL form here:
https://wiki.mozilla.org/WebAPI/WebMobileConnection. We've started the
implementation in
https://bugzilla.mozilla.org/show_bug.cgi?id=webmobileconnection. As
you can see from the wiki page, there are still some open questions
about some radio features. Comments are, as always, appreciated.


P.S.: I will most likely not be able to attend tomorrow's WebAPI
meeting. Can somebody put this on the agenda? Thanks!

Subhabrata Biswas

unread,
Mar 9, 2012, 10:41:33 AM3/9/12
to mozilla.d...@googlegroups.com, dev-w...@lists.mozilla.org
Some properties of the network currently in use should also be made available (e.g. MCC, MNC, Cell id, LAC, RAC, etc. for GSM networks).

Can there be an API to trigger a network scan and another to trigger a network detach and re-attach?

Roaming departments of GSM operators will love this capability because almost all GSM operators have invested big-time in a technology called Roaming Traffic Redirection (or Steering) which is a back-end network based solution for helping roaming subscribers latch on to networks where they can get optimal service. Because of this, a subscriber may suffer a bad experience in areas where the most preferred network does not have adequate coverage. The home network has no way to know this because they have no control over (or knowledge of) the radio network of a foreign operator.

So, if they have a way to grant service to a non-preferred network temporarily but move to the subscriber to a better, preferred network when its service becomes available, it will be a win-win for all.

If this capability of detaching and re-attaching is available, the back-end technology provider can then provide a handset application to check if the current network is the preferred one and if not, whether the preferred one has coverage. In case of non-coverage, it can keep monitoring the status periodically and trigger a re-attach when the preferred network is in range.

Reason for preference? Say Network A has roaming agreements with Network B and C but pre-paid roaming agreement (yes, that's a different beast) with Network B only. Now, if a pre-paid subscriber latches on to C, he/she will not be able to make calls or send SMS. That's degradation of service! However, if the home operator can ensure that the mobile latches on to B soon after it comes in range, that provides the best possible service to the subscriber and salvages the situation to an extent.

Subhabrata Biswas

unread,
Mar 9, 2012, 10:41:33 AM3/9/12
to mozilla-d...@lists.mozilla.org, dev-w...@lists.mozilla.org
0 new messages