On Mon, 2010-09-27 at 17:49 -0500, d.w. harks wrote: > With rapier wit and elegant prose, Inaky Perez-Gonzalez wrote: > > On Tue, 2010-09-28 at 06:30 +0900, Stephen Hemminger wrote: > > > On Mon, 27 Sep 2010 10:47:37 -0700 > > > Inaky Perez-Gonzalez <inaky at linux.intel.com> wrote: > > > > > > > Hi Stephen > > > > > > > > > > > > > The driver is a mess, I have a long list of changes that need to be done, > > > > > the biggest is that the user space and API model are a mess. It really needs > > > > > to be completely rewritten. > > > > > > > > Could you do a write up of what is the API model? Additions will be > > > > needed to the minimal stack that there is now and I'd like to start > > > > thinking about them. > > > > > > > > Thanks! > > > > > > > > > > The existing code uses a single character device. Read/write are > > > control packets, and it has a long list of ioctl's to do things like > > > check link status etc. They also have a binary format configuration > > > file that is read in like firmware at the startup. Much of the configuration > > > can probably be eliminated and the rest can either be done as module > > > parameters or config fs. > > > > Ugly, very > > > > So this is probably an HCI for driving the scanning and connection > > process. It'd be interesting to find at which level the device operates, > > if at the NSP level (like the current Intel devices) -- aka, deals > > directly with base stations and then system software has to map that to > > NAPs (access providers) or if it deals directly with the concept of > > NAPs. Bah, I mixed terms -- Monday!! Where I meant NAP I meant NSP and viceversa -- sorry for that. > > Eventually we need to add a NAP interface to the WiMAX kernel stack so > > that low level system software only has to scan for NAPs and connect to > > them and deal with authentication parameters, so if we can find out how > > beceem does it, it'll drive feedback in the design so it works for all. > > >From what I can tell it's running at the NAP level. When you initiate a > network search, you get back a list of base stations by BSID & > frequency, and the reference Connection Manager configuration Sprint > provides literally gives a list of frequencies to search. Ok, so it is working at basestation NAP level There is some experimental work I (op_nap_scan branch in my repositories) I haven't finished for adding a NAP interface to the WiMAX stack that a generic daemon could use in user space to map NSPs to NAPs, so that it can offer an NSP interface for connection managers (and thus users only have to worry about connecting to their network, not deal with basestations). The implications of NAP interface are mainly at scanning. There are a zillion channel combinations, so you have to be smart on how to scan so it doesn't take for ever to scan and drains your batteries. The basic algorithm a few of us came up with in a few chats over beer was to have a long list of channels (basically every channel supported by the device) sorted by 'score'. When you scan and find networks on said channel, you increase the score X, otherwise you decrease it X, when you connect to a NAP in a channel, it's score is increased 4X, when you fail to connect to said NAP in the channel, the score is decreased X/2. When the device errors scanning the channel, the score is decreased 4X. When the networks provide announcement of neighboring base stations, each's channel score is increased 2X. There were some more details on increasing the number of scanned channels from the top of the list when you repeatedly call 'scan' and making X being a factor also dependent on when was the last time the channel was scanned, but those are tweaks to the basic algorithm. So after some usage, it boils down that you will have the channels you most frequently use automatically bubbling up to the top, so they will be scanned first. To make bootstrapping easier, we would have configuration "priming" known channels' scores for the different networks (Clear, Yota, UQ, etc) -- this information could be yanked off OMA-DM once operative if we had an OMA-DM client daemon, but we can do without it, at some point the system would be self-sustaining just with the neighbouring information the basestations broadcast.u Other devices I've heard of work at the NSP level, so at some point we'd have an 'module' in user space doing the translation and calling the NAP kernel interface or straightforward calling the NSP kernel interface. > There is a userspace shared library which implements the interactions with the > character device Stephen mentions, providing the WiMAX Common API. That API is not ok for linux low level service standards, if you ask me ... conceptually speaking is more or less ok in general terms, but implementation wise it is not.
