>From: ext Inaky Perez-Gonzalez [mailto:inaky@xxxxxxxxxxxxxxx] >Sent: 5. joulukuuta 2008 21:43 > >On Thursday 04 December 2008, juuso.oikarinen@xxxxxxxxx wrote: >> >From: ext Inaky Perez-Gonzalez [mailto:inaky@xxxxxxxxxxxxxxx] >> >Sent: 4. joulukuuta 2008 21:33 >> > >> >> I agree with you. The best solution would be a fusion. A netlink >> >> message based interface with the abstract WiMAX operations (with >> >> interface abstraction at the level used in the Nokia driver) >> > >> >would be >> > >> >> the way to start defining a uniform WiMAX driver >interface for Linux. >> > >> >Well, no ioctl is the way, it has to be netlink. >> > >> >What set of calls/signals do you propose that should be in >the kernel >> >interface? >> >> Our current set, from a very high level point of view, the current WE >> header: >> >> - do WiMAX NAP scan (given a list of channels, returns found >channels >> with NAP id, RSSI, CINR) > >Yep. I am assuming you mean extract the NAPid from the base >station addresses right? The chipset we use only gives NAP identifiers as result for network scan. The Nokia driver only reports that NAP. In the model we're using, the NAP is the network identifier level exposed to user space. The selection of BS is done by the chipset, based on the NAP. Therefore BS address will be known only upon connecting to a NAP. Therefore, in our interface, the BS address is sent to the client during the connect procedure, as soon as it becomes known. In general, we see the driver interface exist on the NAP level. BS selection is driver/chipset responsibility, as well as handovers from BS to BS within a NAP. > >> - do WiMAX NSP scan (given a channel and NAP id, returns NSP >id list, >> verbose name list, change count) > >Unless the hw provides the facility, this should be done at >user space The NSP <-> NAP mapping requires >provisioning/networkin knowledge information. So this would >build on top of kernel-based NAP scanning. Currently, the NAP-NSP mapping is done in user-space only, because networks do not support full NSP discovery. In the (relatively near?) future, networks will be able to give out information of NSP's that are accessible thru a NAP, so that a client may dynamically configure itself. The selection logic will still reside in user space, but a driver interface is needed to get the NSP information from the network. >> - do connect (given a channel and NAP id) > >> - do disconnect >> - get serving BS info (returns channel info and BS id of the serving >> BS) > >What do you mean with 'serving'? I use the them "serving" to refer to the BS the device is currently connected to. >> - get NSP realm (returns the NSP realm string) > >This is another case of needing NSP/NAP mapping, based on what >the hw supports will have to be done in user space or kernel space. > >> - get neighbor list (returns list of current advertised neighbor >> basestations, channel and BS id) > >What do you need this for? Handover? > >> - get last error (returns code indicating last error) > >Why? Each operation, when it fails should return an error; >relying on an extra op to get you the last error opens a lot >of windows for race conditions. You are totally right. We have this problem even now, but there is no other decent way to do this with WE. If netlink based messages are defined, this should be done as you say. >> - set EAP result (used to indicate whether EAP failed or >alternatively >> specify the MSK to the driver) >> - set config (used to configure things like idle timeout, >idle paging >> timeout, etc) > >This is also very HW specific; the intel hw has it, but others >might not. This is partly true. The idle-timeout is somewhat HW specific, but, for example, the idle paging interval is not - that is something agreed between the device and network, and there should be opportunity for the host to configure it. >> Wireless events are used to notify the client of events. Obviously, >> they're used with things like connect to indicate >completion, scan to >> indicate available results and completion, etc, but there are some >> special events too: >> >> - "realm available" the realm becomes available during the connect >> procedure, this indicates that it can now be retrieved >> - "bs info available" info on which BS the device is going >to connect >> to becomes available during the connect procedure, this >indicates that >> it can now be retrieved >> - "ip renew" it is possible, that due to handovers, the DHCP renew >> needs to be executed although the connection never went down >and lease >> never expired, this is to indicate that >> - "neighbor update" indicates there were changes in neighbor bs >> information >> >> There are lots of parameters affecting detailed behavior. I would be >> happy to provide a more detailed design, with sequence charts, for >> this interface. I would be happy to write a template for message >> structures too if there's interest. > >There is -- keep in mind, however, that for the case of the >i2400m, the kernel cutline has to be at the NAP level. All the >NSP operations will have to be implemented in user space using >the NAP-based primitives offered by the driver/hw. AFAIK this is a logical point for the cutline. In my perspective, including NSP level stuff in the chipset would seem to include lots of device independent code in the device, which really shouldn't exist there. -Juuso >> >I really don't want to set this on stone until there is at least a >> >second vendor coming in, but that doesn't mean we can start >thinking >> >about it. >> > >> >BTW, where can we find your user space code? >> >> This is not as simple as I might hope :( Although open source EAP >> stacks exist, Nokia is currently using a proprietary one, and its >> sources are not available. The daemon component (called "wimaxd") is >> open source, but is currently not available, but there is >work ongoing to make it so. >> It will be in the same repository as the kernel sources. >> >> To be truthful, however, the network selection logic (and OMA DM) is >> proprietary, and most likely will be for some time in the future. >> These are considered "differentiating" features. > >Well, that's a problem. Without that, we are dead on the >water. This is the most important chunk of code once you want >to do real use of WiMAX outside of a lab. > >We have the network-service tarball, which implements that >part and we are shaping it out, but it takes time. For now it >works. Baby steps :) > > >-- >Inaky >
