On Wed, May 14, 2008 at 8:28 PM, Juliusz Chroboczek <[EMAIL PROTECTED]> wrote: > > soo... http://wiki.laptop.org/go/Mesh_Network_Details#Experimenting - > > they've ... oh. they cheated. they got marvell to do some of the > > low-level mesh networking. > > It was my understanding that OLPC and Marvell collaborated on the job. > In particular, I believe that Michail Bletsas invested a lot of work > into the mesh implementation.
oh right. cool. > I may be wrong, though. one can always find out - thanks for the pointer and the qualifier. > > so, not only am i going to need to merge all the different types of > > communications technology together but also i'm going to need to send > > certain types of traffic (voice, video, jpeg images) over the > > different communications networks, selecting the "best available" one > > for the job. (!) > > That's called policy routing, ok. well, i was quite happy to manage it myself - but... [carrying on below] > and there's a lot of published papers on > the subject. Babel doesn't do policy routing right now, but if you > convince me why it's needed, I'm quite willing to add it. ... what you're saying is that it's not straightforward to identify / separate the networks, is that right? i was kind of naively envisioning that i would be able to just bypass the routing, for voice, and go direct to e.g. the packet radio modem interface. > The reason I'm not convinced of the need for policy routing is that > there usually the best link for one type of traffic is also the best > link for all other ones. There are exceptions, but I'm not sure > they're common enough to justify burdening your routing implementation. the situation will be thus: occasionally, the device will be in range of GSM / 3G celltowers. sometimes, it will be in areas where cell coverage is patchy. sometimes, the WIMAX might work, and at other times it will lose lock because the person went into a lift. sometimes, the radio-modem will be the only network; sometimes even _that_ might fail, or the users will be too far geographically separated - or they will be at home instead of at work and the only way to contact them is via GSM. so it's going to vary dramatically, and the users simply won't care: they will just "want it to work". > > > yes. ppp over GSM/GPRS; WIMAX; 802.11; radio-modem; all of it has to > > be sort-of... merged amorphously. > > Yes, but. :) > If I read you right, you're not only asking that routing decisions be > made depending on the available technologies; you're asking that they > be made depending on offered load. In other words, if both the radio > modem and GPRS are available, you want the radio modem to be used if > the offered load is less than its capacity, but switch to the expensive > GPRS link if the offered load increases, e.g. because the user decided > to start a video conference. > > Is that correct, not entirely... > or are you happy with all traffic taking the ``best'' > link available at a given time? it's "out of my hands" so to speak. > (Once again, if you need policy routing, it's your task to convince me.) well - the additional complication is that some people will be contacting (calling) specifically over the radio modem; other people will be contacting specifically over the GSM / GPRS. also, the radio modem side already has "broadcast" capabilities - which, fortunately, are mature and well-developed, and part of the standard off-the-shelf products. these radio modems _happen_ to offer an extra channel (appx 4800-baud or so) for TCP/IP which can operate simultaneously with the VoCoder (voice channel) functionality. so, the available (and very restricted) bandwidth on the digital radio should be considered to be "valuable". in other words, any person (or multi-call group in the case of the radio modem) that is to be contacted, it's important to know _how_ to contact them - i.e. on what interface. it's no good trying to communicate with a person whose telephone number is 555 121 2121 on the WIMAX link ;) it's all kinda fun, you know - kinda exciting. i'm just spinning my wheels at the moment, waiting for those damn lawyers to get off their backsides and sign the damn paperwork :) > > e.g. if you can transfer _some_ routing information - however slowly - > > about the 2-mile-range WIMAX nodes over the 10-mile-range radio-modem, > > then you would, i assume, be able to make better routing decisions > > than you would if you didn't have the long-range radio connection? > > Do not worry about the routing traffic -- it's very low rate, on the > order of 1 byte per second per node. oh, excellent. > No need to use third-party > announcements (which is the technical term for what you're suggesting) *thinks*.... ok, so what you're saying is that the routing traffic - and the babel algorithm - is good enough to create a stable network, without needing any kind of "augmentation"? ok .... *thinks*.... let me try to think of a scenario which would benefit from cross-media ... ok - how about this: WIMAX network 1 <-> GPRS / 3G <-> WIMAX network 2 so - a network comprising two WIMAX networks which are geographically too far apart to be connected together (more than 2 miles) but a few of the nodes can use GPRS / 3G to get data across between the two, thus connecting the two networks together. ... does that work? the second potential scenario is one which merges the use of the broadcast capabilities of the digital radio modem, augmented by GPRS / 3G to broadcast-communicate with many groups across a country or even the world, simultaneously. i have to be honest though, that i doubt that this particular scenario (worldwide broadcast) is even on the client's radar. the WIMAX-net-1 <-> GPRS / 3G <-> WIMAX-net-2 one almost certainly will be. for that kind of scenario, with permanently-or-temporarily disconnected networks (the WIMAX network gets split in two halves), would it help to have some routing traffic be sent over the GPRS / 3G? and, more importantly, is it possible for babel to still maintain a cohesive virtual network, independent of the link layer(s) being used to create it? > >> notably what kind of hand-off times are tolerable, > > > walking around inside and outside office buildings, which might cut > > things off randomly, but assume decent antenna (4 or 8-way phased > > ceramic antenna). > > Suppose that user walks into a lift, and the WiMAX connection is cut > off. Is it okay if the mobile node switches to GPRS after one second? > 5 seconds? 15 seconds? to be honest, i don't know - i'll have to find out, once the contract's signed and i find out from the customer what the clients will find acceptable. but, i know that with Motorola closing the doors on TTPcom last week, there are a hell of a lot of good engineers wandering around cambridge at the moment, and the whole damn reason why motorola bought TTPcom was because they're one of the few companies that have managed to solve the "seamless GSM-to-WIFI-and-back handoff of phone calls" issue. > >> whether you're interested in multi-hop routing, > > > yes. > > Good. :) > > > so - like the OLPC thing [except better :) ] assume that it's got to > > work without centralised infrastructure, but if centralised > > infrastructure is available (e.g. GPRS / 3G or a high-power > > fixed-position WIMAX unit that has better range and coverage than the > > mobile units) then it should be seamlessly taken advantage of. > > No problem, we already do that. yaay :) > But see above about policy routing. ack. > > >> how large is your power budget, > > > luggable rather than portable. i.e. "big enough" to not have to > > worry about :) > > Good. > > > >> and whether you can count on link-layer notifications. > > > > does this mean "inter-layer" notifications? i.e. like i hinted at > > above, about being able to send notifications over the radio-modem > > about the e.g. WIMAX layer? > > No. > > Link-layer (or, more generally, cross-layer) notification is about the > link layer informing the routing protocol about the link being > broken. oh - ok. > In other words, you loose WiMAX connectivity, and the WiMAX > driver informs the routing daemon that the WiMAX link is down faster > than the routing daemon would realise that it's no longer receiving > anything over that link. ohhh, ok. hey. that's smart. so to answer your question (now that i understand it :) ) - regarding the packet modem: i don't honestly know, i'll have to find out. as i understand it, it's pretty much a "black box". i'll have to get back to you once i know more about its capabilities. regarding GSM/GPRS weeelll... :) we can get "signal strength" of the nearest celltower... hmmm... > It allows faster convergence, since the routing daemon does not need > to explicitly probe the broken link. So it's linked about the point > about hand-off above. ok. thank you! sooo.... it appears that i have quite a lot of things to find out :) thanks juliusz. l. _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/babel-users
