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. (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.)
-----------------------
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.
-----------------------
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?
-----------------------
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.
-----------------------
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.
