I've written before about the critical importance of "WiFi Neutrality" - the ability for the end-user, device OS or applications to choose which WiFi connection to use, over-riding any operator-defined preferences if such exist.
The critical control point is the "connection manager" on a device - the bit of software that determines which accesses are available, and how/when to connect to them. For WiFi, this is usually done as a core role of the device OS - most people are used to seeing the Windows or Mac choices for WiFi APs, or a similar function on their smartphones. For cellular connections, it doesn't really exist as such on phones (beyond a primitive menu somewhere with auto/manual network-select). But on laptops, there's usually a customised client from the operator that gets auto-loaded when inserting a 3G USB dongle for the first time, or pre-loaded if it's got a built-in module.
I've long predicted that the CM would become a strategic battleground, especially for the WiFi aspects. Much to service providers' continued annoyance, most WiFi isn't a service at all (ie at a hotspot), but is just a wireless connection to a local LAN. The biggest use of WiFi is for connection to a fixed-broadband router or gateway, and then direct to the Internet. Various other LAN use-cases are important as well, notably enterprise network connections, or UPnP links to other devices in a user's home (TV, printer, server etc).
The mobile operator community would dearly love to have greater control and visibility over users' WiFi connections - ideally capturing data connections and putting them through the core network (for billing, charging, policy, QoS reasons etc). "Uncontrolled" (ie user-driven) WiFi connections are often seen as undesirable because they represent a second access path for data on or off the device. This both implicitly reduces the perceived value of the paid cellular/hotspot connections, and also allows easier access to applications that the operator may not want (eg competing VoIP).
The Open Mobile Alliance is currently working on a "solution" for the fact that CM's currently are not standardised. The Open Connection Manager programme and its associated APIs are being worked on by a group of its members (Intel, Orange, Huawei, HP & Deutsche Telekom) with various objectives.
"Up to now, there is no existing standard or de facto standard for Connection Managers. Operators and OEM/ODM have to develop and use different and dedicated solutions, thus increasing the effort and time to market.
For Mobile Broadband devices, this situation is critical and leading to a strong effort for service providers to develop connection manager applications as there are already several networks to support and any new mobile broadband device such as USB modem requires to redevelop existing connection managers to be implemented and supported by these applications.
For smartphones or tablets, the importance of management of Wi-Fi offloads for example and/or the need to expose information status on the connection to applications is requiring a solution through the connection manager application.
Furthermore, new fast growing businesses such as Connected Devices & M2M are facing the same hurtles and will need as well a solution to reduce the impacts and efforts to deal with the connection management aspects."
Now, for cellular data connections this is fair enough. There is a fair amount of work needed to reinvent the UI for each new device or module, so standardising some aspects certainly makes sense.
For WiFi, however, the situation is much murkier. There are already various efforts such as Hotspot 2.0, I-WLAN and ANDSF which are attempting to "steer" smartphones to use operator-provided WiFi. The dreaded term "seamless offload" still crops up regularly. While I've had some positive recent conversations with operators and vendors - who realise that control over WiFi ultimately should and will continue to reside with the user, I'm not so sure that OMA has got that particular memo.
"The OpenCMAPI enabler SHALL be configured to use the operator defined list of preferred SSID preconfigured in the device and/or the WSID (Wlan Specific Identifier) list in accordance with [3GPP TS 24.234] if present in the SIM/RUIM/NAA on UICC"
"The OpenCMAPI enabler SHALL be able to force the association on a SSID, visible or not"
"The OpenCMAPI enabler SHALL be able to modify or delete only WiFi profile that are not predefined by the operator"
Now to be fair, it also says this:
"The OpenCMAPI enabler SHALL allow the user or the application using the Open CMAPI to connect to Known network or Unknown network manually"
But it's entirely unclear how that will work if that conflicts with the previous requirement. So for example, could an enterprise user delete the operator's WiFi profile & stop offload, if they decide it is incompatible with their security policy?
The bottom line is that as far as I can see, the OMA Connection Manager API sits very uneasily with the concept of WiFi Neutrality - I really can't see many device vendors (especially Apple) relinquishing control of this pivotal part of the stack. In any case, the Open CM is unlikely to be seen as a useful basis for the expanding number of WiFi-only devices.
If implemented in this WiFi-unfriendly fashion, it is also going to be something that will further dissuade users from buying 3G-embedded laptops (which I've been negative about for years), if the operator also controls the WiFi connectivity settings. You don't let a service provider dictate how you use your USB ports or fixed-ethernet RJ45 socket on your PC, so why on earth would you accept controls on the wireless-ethernet?
I have a simple adage with anything to do with WiFi : If you don't understand fixed ethernet, then you have no business doing anything with the wireless version either. Quod erat demonstrandum....
0 comments:
Post a Comment