Thanks for summarizing, Oleg -- all, sorry for having started this online, but it started as a question and evolved into a long thread before we realized it should have being done publicly (thanks again to Oleg for bringing it up). Below some more responses/comments On Mon, 2009-09-07 at 10:05 -0600, Yakovenko Oleg wrote: > All, > > We've been discussing different kinds of devices with Inaky and others > (offline). Here I'd like to summarize/continue our discussion so that > it's available to everyone. > > To start with, two kinds of user devices exist so far: NAP and NSP. > Here is some definition (by Inaky): > > Connectivity provider: VNO (virtual network operator) > A VNO runs on one or more NSPs > (for example, MyCompany could provide connectivity using Yota's > network in Russia, Clearwire in the US under the same credential). > network: one or more NSP networks > NSP: provide connectivity, serviced by different NAPS > NAPs: set of basestations (NAPs) with the same operator ID. > > So a NAP (basestation) belongs to some guy who provides access to a > number of NSPs (connectivity providers). The NSPs resell the service to > the Network Operators. Of course, the VNO, NSP and NAP could all be the > same entity. > > So the basic interface for all is the same: > - NAP: connect / disconnect, scan for NAPs > - NSP: connect / disconnect, scan for NSPs > ----------------------- > > The proposed architecture for wimax stack is as follows: > > Conn Manager > | > wimax dbus API > | > /-------------\ > | | > NSP-to-NAP | > mapping | > -------|-------------|---- user/kernel interface > NAP inteface | > | NSP interface > | | > -------|-------------|---- wimax stack / wimax driver > driver A | > backend for | > NAP interface | > driver B > backend for > NSP interface > > The idea is that every component other than a driver will be common for > all devices. There are things that devices do differently and we will need "plugins" to handle things differently for some class of devices vs other. In the diagram above, an example of that is the "NSP-to-NAP mapping". The Intel devices do it in a way, the Fujitsu devices seem to do it in another and hopefully we won't find much more variations. Other operations (rfkill, connect, disconnect, etc): difficult will be for devices to implement different conceptual ways to do it, although you never know what hw designers will come up with :) > (However I have a question here: how do we handle private > message exchange (op-msg) between a driver and a user-space component > given a user-space component is common.) well, that's private. The private channel is left there for whatever operations are impossible / make no sense to abstract out. Things like field diagnosis, factory testing, flash upgrade (see below)...come to mind. For this, each device would have it's device-specific utilities, but these are not expected to be used commonly by a normal user. Hence, they can be left out. If anyone finds an abstraction level that works for some aspect of it, then we can always introduce new interfaces to handle them. A case of everyday use that needs the private interface is the Intel device's supplicant. That runs in user space and uses the private interface to do the crypto setup every time you connect, but it is completely hidden from the user and so specific to the Intel device that makes no sense to abstract it out. > ----------------------- > > There is an open (minor) question on how to handle firmware updates. > Since different devices require totally different update-procedure it > looks non-trivial to come up with some kind of an abstraction layer. This ties some bit into what OMA-DM denotes as "need to upgrade". However, it is not clear at all what different carriers mean with this, being the host stack also possibly involved in the sense of "need to upgrade". Firmwares/upgrades can involve: - for devices with flash, upgrading the flash'ed firmware; this might require an special tool to do the job - for devices without flash: upgrading the firmware in the system's filesystem (eg: upgrading an RPM/deb that contains said firmware) - update the host software? anything that invovles upgrades in host software invovles interacting with the package manager in the system. We already have rpm/deb/x for that, so this becomes an integration problem. The only thing we need from OMA-DM is "need to upgrade" (maybe adding "to version X of whatever"?).[ > While a NAP interface is almost defined and coded, the NSP interface is > not yet defined. No official information from any vendor is available > yet to clearly define this interface. Does anyone have such > information? Not so far, but it will resemble a lot the NSP level interface defined by the common API (see the link in the website). Most HW manufacturers are doing stuff so that something like that is supported. > I have quickly reviewed an op_nap_scan branch (the development of NAP > interface API is going there). Is there a user-space component > available which works with this version of WiMax stack? I'd like to > try to look deeper into it. Yes, see the op_nap_scan branch of the wimax-tools package (the command line utility is wimaxll and the nap-* plugins implement the raw functionality you are looking for). I am looking as time permits at implementing the starts of the daemon, but still I have nothing that really does anything useful. I need to put together the loose bit and pieces I had spread around my drives and publish it). > There also was some discussion with Dan W. I'd also like to share this > for everyone's information: > > [Oleg] In addition to this there is a port of the madwimax project to > the kernel space. > (http://git.altlinux.org/people/silicium/packages/kernel-source-u200.git). > Note that they create an interface with wireless extension and it can > be managed by iwconfig and other tools. > [Dan] Using wireless-extensions is EVIL. We're trying as hard as we > can to kill it because it's a horrible API and completely > non-extendable. This was the main reason why Inaky and the Intel guys > created the netlink-based API for WiMAX. > It would be good to get everyone using the same API, then we dont' have > to update every connection manager every time a new chip comes out or > the firmware interface changes. That's the whole point of abstraction. > > >From my perspective (I work on NetworkManager), I don't really want to > write a new shim layer for every new wimax part that gets released. I > want the driver to provide a common interface (or, really, have the > Wimax Network Service provide the common D-Bus interface) and then have > NetworkManager talk the same protocol/API to every card. > ... Amen to all that :) -- -- Inaky
