Peer-to-Peer Cellular 145
Phos writes: "A cool article over at the O'Reilly Network outlines a possible solution to cellular network outages in the event of an emergency. A P2P SMS technique where individual handsets act as autonomous SMS relays."
Sounds cool... (Score:3, Insightful)
Re:Sounds cool... (Score:3, Insightful)
Although a completely P2P cell phone network sounds cool, it's not very feasable with our current phone system.
Re:Sounds cool... (Score:3, Interesting)
Re:Sounds cool... (Score:1)
Re:Sounds cool... (Score:1)
Peer-to-Peer (Score:3, Funny)
Great - ez-SMS spam (Score:4, Interesting)
I'd give it a week before an open cellphone is considered as antisocial as an open smtp relay.
They just had to do it... (Score:4, Insightful)
Gnutella is a completely decentralized, or peer-to-peer, file-sharing system. Unlike Napster, there is no centralized server that acts as a broker in processing search requests, matching users with each other. Gnutella clients automatically seek out other Gnutella clients elsewhere on the Internet.
(I guess gnutella is free from lawsuit then?)
I'm not so sure I like the idea: what if some cell phone junkie figures out a way to display all of the messages coming into his phone (a friend of mine can do similar things) and he gets to read everyone's text messages... not a good thought.
Re:They just had to do it... (Score:1)
Easy answer for that: End-to-End Encyption.
Just like SSL works. Ofcourse if you're in the USA you'll have to include a backdoor... Oh, nevermind.
Re:They just had to do it... (Score:2)
That would cut down on spam (and you could always autoreport spam to your provider afterwards). As for privacy in your text messaging, it's the least of your worries during an emergency. 99.9% of the messages are going to be of the "Are you still alive" variety. Only if you expect to be exchanging sensitive information do you need the end-to-end encryption. And since end-to-end encryption also requires you to exchange keys, it could stress the network further.
Network stress is my main concern. Gnutella has some well-documented limitations, particularly the exponential increase of requests as the network grows. In this case the phone is looking for the closest route to a base station though, so it won't be too bad. It just can't replace the main network completely. The other problem is (potentially) memory.
Re:They just had to do it... (Score:2)
Re:They just had to do it... (Score:3, Insightful)
Re:They just had to do it... (Score:2)
Mini Towers (Score:1)
MUHAHAHAA
Signal power of a mobile phone? (Score:2, Interesting)
A base-station is built to receive signals from mobiles far away and is usually equipped
with large antennas and located at a high point.
But the range for mobilephone2mobilephone
communication shouldn't be so long.
A mobile phone signal is very weak.
In the article they are onle talking about the network aspect but not about the "mobile" aspect.
Has anyone an idea about that?
Re:Signal power of a mobile phone? (Score:1)
Re:Signal power of a mobile phone? (Score:1)
Re:Signal power of a mobile phone? (Score:3, Informative)
Typical cellphones are a few hundred milliWatts.
A tower can punch out power (in some cases) up to 60 Watts or more, though it doesn't usually.
At least that was how it worked for cell data systems such as CDPD. Cellphones are probably analogous. I think when they try to either acquire a channel or when they are broadcasting, they can amp the power up (I'm not sure quite at what starting level they use) up to 200 or 300 mW max. If you have one of the in-car systems, you can go up to 2 or 3 W. (Considerable increase in range, and the big ass antennae helps receiving fainter signals). Towers can pretty much always reach a phone that can reach them. Usually it is the phones returning signal that drops below the noise threshold rather than the signal from the tower.
FYI... (from memories a couple or four years old).
Tomb
Battery Life (Score:3, Insightful)
When your phone is idle, you don't use much battery life. My phone, for example, can last about a week with only a small number of calls and most of its time being idle. This is also in areas where the signal strength is at least 60%.
I'm sure many Slashdot readers know that modern cell phones increase their power when signal strength drops below a certain level. I'm sure you also know that when the transmitter is active, you use a lot of energy. So now that my phone is a node, not only is my transmitter probably constantly on (thanks to the people who can't live without talking on a cell phone), my battery will drain within a few days to hours, and to top it all off, making it more of an EMF hazard to me; the transmitter is what tauses dain bamage.
Cool idea, but I'd at least like the option to turn it off.
Re:Battery Life (Score:4, Insightful)
Re:Battery Life (Score:1)
This could be of immense help during emergencies as people in car would help others in relaying messages. Volunteers can bring a suffecient number of cars near the emergency accident site to allow people to communicate (large number of base stations nearby should help save battery life for people buried in rubble).
Re:Battery Life (Score:2, Insightful)
SMS messages aren't going to take too long to relay, and the time during which your phone is connected during the relaying will be very low.
Re:Battery Life (Score:3, Insightful)
Individual messages, maybe not. But thousands of messages -will- hit your battery.
SMS is little used in the US (people still think 'bleeper' for messaging services). But in the rest of the world, especially Europe and Japan, SMS is king.
I send/recieve 5-10 a day and think nothing of it, and I am a light SMS user. SMS actually comprises a signifigent fraction of all network traffic over here (a year ago I heard figures of over 6 million SMS's a day, in a country who's population is only 18 million. The Netherlands)
Re:Battery Life (Score:1)
Re:Battery Life (Score:3, Insightful)
Also, maybe there could be a way that the system could be thrown into an emergency state to preserve batter life. In other words, there could be a way to get messages to the local 911 dispatcher. If a certain number of 911 requests are detected by a single phone, then that phone can send out a message that switches all the other phones into an emergency mode, in which case only high priority messages are allowed through.
Re:Battery Life (Score:1)
2) Something like this should probably only be invoked in the case of an emergency, and perhaps some sort of emergency key would need to be broadcast to activate this mode. In the event of such a local emergency, I'm sure no one would mind their cellphone being commandeered to allow fire and rescue coordination traffic to get through....
(Or course, insert mandatory cautionary note about hackers....)
Tomb
Re:Battery Life (Score:2)
making it more of an EMF hazard to me; the transmitter is what tauses dain bamage
Only when the phone is next to your head! Unless you have a headband securing your mobile to your ear to improve call response time?
Phillip.
Not only in emergency (and two wishes). (Score:2, Interesting)
An easier solution, and also useful, would be the ability to send local messages, without network support. The problem here would be reluctance from the network operators as they would loose revenues.
As we are on the subject, all cell phones should have an "offline" option when you want to read/write messages but are not allowed to or do not want to be connected.
this is a nice idea but... (Score:4, Insightful)
Re:this is a nice idea but... (Score:1)
You're not necessarily trying to get to the target phone. You mayb just have your local base station down, in which case you're trying to get your message to any other phone that's near a base station.
I would assume that in most urban settings it would only be a couple of hops until you hit a cellphone that's on the main network.
You can just send the message to all of the phones in range if necessary, although that would be pretty inefficient. Otherwise you can use some pretty simple routing...
Re:this is a nice idea but... (Score:2)
while (death_and_taxes) {
again:
Try to find tower();
if towerfound {
set level=1;
while (stillconnected) {
mainloop();
}
} else {
for (i=1; i<=10; i++) {
trytofindpeeratlevel(i);
if (peerfound) {
set level=i+1;
while (stillconnected) {
mainloop();
}
goto again;
}
}
}
}
Re:this is a nice idea but... (Score:3, Informative)
No, it doesn't. Rather than try to explain why not, I suggest you read Ad Hoc Networking by Charles Perkins (editor) or the papers and references from the IETF MANET working group, or some of the stuff from CMU or Cornell. In short, an end-node usually only needs to know about its immediate neighbors, plus a modest amount of information regarding location (either physical or abstract).
Absolutely not.
Wrong again. Both end-to-end and in-network retransmission and acknowledgement can be used to prevent such loss even in the face of multiple failures. That's just basic networking, not even specific to mobile networks.
The problems you mention are real, but don't assume that solutions do not or cannot exist just because you weren't able to see them after a few minutes' worth of independent thought. Some pretty bright people have been working on them for twenty years or more, not without success, and before you assume "it won't work" you owe it to yourself to find out whether you've been proven wrong already.
Re:this is a nice idea but... (Score:2)
But what about recieving messages?
Re:this is a nice idea but... (Score:2)
keep track of which phones report they have an uplink, and send through them
assuming some sort of circular route pruning, it wouldn't be too hard
my point was downstream (to the phones) is going to be difficult anyhow
Re:this is a nice idea but... (Score:3, Insightful)
The phones would need to have the ability to get confirmation of message delivery. That way, the phone would first try to send a message via route A, then route B, until it gets confirmation. It would also need to be able to determine if a certain route is a dead end, meaning the last phone in the chain can not relay the message any further. Delivery confirmation could be sent backwards, along the same route that the message used assuming all the chain links are still in place.
Won't this overload real fast? (Score:1)
Battery life (Score:2, Informative)
Battery life no worse than "normal" (Score:2, Informative)
If you have lost connection to the main network, then battery life is going to be short anyway. Currently, your phone operates at the lowest power possible to be able to communicate with a cell tower. (And if you think your phone only transmits when you are using it, try putting it on top of a computer monitor, they transmit quite frequently). When there is no tower available, your phone will increase power until it successfully contacts a tower or hits the max power.
The longer you are out of the area, the shorter the time your phone's battery lasts.
It already exists (Score:5, Informative)
It's called Amateur or 'ham' radio - every year they have an event called 'field day' which is an exercise in taking your gear out and operating on generators, etc. 2 Meter handy talkies can work thru a repeater or direct simplex (peer-to-peer) if the repeater is down.
I'll never forget listening to a ham during hurricane floyd, w/o power, operating on emergency backup power, 80 meter band, crouched in his garage on the NCarolina cost reporting the fierce winds in the night.
Re:It already exists (Score:4, Interesting)
Actually, I wonder... is there a subculture out there of people using hacked cellphones for legitimate, i.e. hobbyist, purposes? I don't mean cell phreakers or people using stolen service, I mean people doing precisely this p2p sort of thing, completely off the nets (or even using their own shadow nets). I can't think it would be that hard to do -- the only problems would be a) modifying the firmware and b) hooking your cell-frequency ham radio tower up to a PBX to connect to the rest of the phone net...
/Brian
Re:It already exists (Score:1, Interesting)
Anyways, the phones could be tweaked to the ham bands with a little bit of work. The ones I saw were only land-line linked through a standard auto patch and they were mainly used to talk to other hams with modified phones.
What a dumb idea! (Score:2, Interesting)
First of all, for a number of technical reasons, the phones cant actually HEAR each other. Yes, the phone receives and transmits on different frequencies, and it cannot receive on the same frequency it transmits. It would of course be possible to build a phone that could receive on the same freq. it transmits on, but that intorduces a lot of problems that are expensive to solve.
So, unless everybody is willing to pay 10% more for their phones, no amount of software will make this work.
And if the hardware did support this, making it work software wise would be quite a nightmare. I suppose it wouldn't necessarily work worse in emergecies, because it wouldnot work well at the best of times either.
Another thing about these phones is that they are about as far removed from the world of open source as you can imagine - much further than Microsoft. The manufacturers wouldn't be allowed to open up the source even if they wanted to.
Re:What a dumb idea! (Score:1)
Proprietary Rights (Score:3, Insightful)
Another issue is one of bandwidth and ranges. Corporations have literally 'bought' ranges in which their devices transmit, or lease these aforementioned ranges to other companies. Yes, people you can buy air - and it's rediculously expensive.
I don't mean to sound down on the idea - I love it. We've unfortunately seen the muscle of larger market providers steer the relatively ignorant halls of justice away from the better alternatives far too often.
Disadvantages (Score:5, Insightful)
-sting3r
Re:Disadvantages (Score:2)
Very good points. Especially the last one about the battery life. Because in the end, even if the providers would not charge anything for the transmission of SMS, there would still be a power cost for the user: the battery power is still a scarce resource. This is not a big problem if each phone is only relaying a couple of messages per hour, but the battery would be quickly drained if the phone had to relay dozens of messages per minute.
There is another minor technical detail that was neglected by the author of the article: the example included in the article uses an XML-like syntax for the message, including some routing information. This is very inefficient and in many cases the message would not fit in a single SMS (currently, SMS is limited to 160 characters per message). The messages could of course be compressed, but the overhead would still be very big in comparison with the size of the payload that can be transmitted. There should be some way to optimize the compression of the routing information, but that is not trivial.
How do you deali with cancer nodes? (Score:2, Insightful)
Re:How do you deali with cancer nodes? (Score:1)
Re:How do you deali with cancer nodes? (Score:2)
Re:How do you deali with cancer nodes? (Score:1)
PCS was supposed to do this (Score:3, Insightful)
Scaling problems. Very nasty scaling problems. (Score:4, Interesting)
Even if almost all of the messages being routed are to phones in the same city, the density of messages at each relay node will be large (total traffic is proportional to the number of nodes talking, and for an even distribution, traffic per node is proportional to the square root of this). A city has a million phones or more. This means that each phone would be routing messages for hundreds or thousands of other phones on a *normal* day. *If* all of the load-balancing in the routing table works perfectly.
Fast forward to Sept. 11th. You have everyone in North America trying to call or message relatives in New York City. The traffic densities as you approach New York would be *HUGE*. Inside the city, you'd have phones trying to handle thousands of messages or *more* at *once*, instead of whenever phone users decided to send. This would melt down the message network in the city and for a little ways around it.
All of this assumes that each phone knows the best route for all messages. In practice, they don't. I'll let someone with more network expertise than I have describe how nasty things get when your phone can only fit a small routing table and you have a constantly-shifting pattern of connections that has to update itself in a decentralized manner (instead of being tracked by a central server that knows where everyone is). Short version: It's not going to be pretty.
In summary, I think that the authours of the article are overlooking a significant problem, especially given that they're proposing this as a way of overcoming system load problems in situations like the Sept. 11th attacks.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
*sigh* -1, Redundant
Exactly the same point was already raised...and answered [slashdot.org].
Re:Scaling problems. Very nasty scaling problems. (Score:2)
Exactly the same point was already raised...and answered [slashdot.org].
*Sigh*.
I was pointing out that even with perfectly balanced, zero-overhead routing, this system doesn't scale well. Arguing that routing is easier than I'm claiming completely misses the point of my post.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
Bullshit. Let me refresh your memory regarding the much broader claims you actually made:
Wrong. Traffic per node in an N-node network is proportional to log(N) - the log base being the average connectivity - not sqrt(N). For a million-node network with average connectivity of four, that's the difference between your figure of 1000 and a correct figure of 10.
...and then when just such a person does provide just such an explanation, showing why a conclusion different than your admittedly-uninformed one is warranted, you claim that they missed your point. Asshole.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
You are making flawed assumptions about the nature of the network.
A cell phone's range, when communicating with another cell phone instead of a tower, sucks. You can model the resulting network as a large grid of cells, with a cell's size being the communications range of a cell phone to another cell phone.
Assume you have a large grid. Assume that people are communicating between random points within this grid.
Traffic only flows to neighbouring cells - your range sucks, as mentioned.
Draw a partition down the center of this grid. Half of your traffic will cross this partition (given random sources and destinations).
If everyone is on the phone, and you have N cells, you have O(N) communications channels, half of which cross the partition, being routed through a region containin O(sqrt(N)) cells.
This gives O(sqrt(N)) communications lines being routed through each cell.
Arguing that that only applies to people near the center of the grid is a cop-out - you'll still have a large fraction of your cells with traffic comparable to what you have near the center, especially since you're spreading traffic routes out to avoid local congestion.
Find a way around that, with the assumptions that I described (array size much larger than cell size with random point-to-point communications requests), and you're a network god. Good luck.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
Nope. You're the one making invalid assumptions, specifically:
These assumptions all combine to paint a much uglier than necessary picture, as we'll see. To deal with the most obviously stupid assumption first, consider that connectivity is actually a product of range and node density. Sure, you won't find many neighbor nodes if you have a hundred devices spread across the entire state of Montana. However, if you have several hundred thousand units within the confines of New York City - our original example - you're likely to find hundreds of potential neighbor nodes even if your range is quite small.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest; that forces me to take "baby steps" even when traversing long distances. Obviously I should send directly to anyone within range, routing be damned. Less obviously, when I need to communicate with someone who's out of range the logical neighbor to route through would be one relatively far from myself (but still with a stable signal). If you envision your network as a 1000x1000 grid, it's as though each hop can cross 10 rows and/or columns at a time. Even better, a couple of wise guys can create a "wormhole" between the middle of the upper-left quadrant and the middle of the lower-right using fixed access points and high-gain directional antennas. The grid concept starts to break down pretty quickly once you actually start to think about it; when you start making more realistic assumptions about topology and routing, the actual hops per message - congruent to traffic per node - doesn't even approach the figures predicted by your severely flawed theory.
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why? In any realistic deployment of such a system, there would be a huge variety of both fixed and mobile nodes, representing a vast diversity of capabilities. I'd have to be an idiot to route through a dozen other people's mobile phones when I'm standing right next to a functioning fixed access point. In reality, the "pure peer-to-peer" routing would only be a fallback, in case someone managed to achieve the nearly impossible task of knocking out every one of thousands of fixed home/office access points in the city. In normal operation, the real routing problem consists of how to route to the nearest "non-peer" - i.e. node with superior capabilities, so the idea of a million-node network composed entirely of celphones really doesn't apply. In reality, the size of any network fragment consisting only of celphones is likely to be from a few dozen to a couple of hundred nodes.
It should be clear by now, at least to any objective third party, how ridiculous your grid example/analysis really is. I may not be a network god, but that's hardly necessary to poke gaping holes in the network-slug arguments you've been making.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
This does not affect the order of the problem. It just affects the proportionality constant when translating O(sqrt(N)) into an actual hard number. Connectivity within a node isn't relevant to the problem. See below before trotting out your formula again.
This brings us to the grid assumption. You're assuming that nodes are incapable of "skipping" a row or column in your unnecessarily-rectilinear grid, but in reality that's not likely to be the case. If I have a couple of hundred potential neighbors, I'd have to be an idiot to route everything only through the ten nearest
I'm already assuming you're routing to the *farthest* possible cell phone. Which is in the adjacent *node*. A node, in my previous post, is a *group* of cell phones.
You want a more rigorous illustration of why you get congestion? Fine:
You have a large area containing cell phones, with very short communications range. You have random point-to-point communication requests within the large area.
Draw a stripe through the middle of the area, with a width equal to the phone-to-phone communication range. About half of the total phone traffic connects people on opposite sides of the stripe.
All of this communication must be routed through phones within the stripe - it's wide enough that you can't just skip over it.
The number of calls/message channels routed through the stripe is proportional to the number of phones, which is proportional to the area (we're in a city with phones uniformly distributed).
The number of phones within the stripe is proportional to a constant (the phone-to-phone range) times the *diameter* of the region - which is proportional to the square root of the area of the region (and hence the square root of the number of phones).
Thus, you end up with a number of communication channels proportional to the total number of phones being routed through a stripe containing a number of phones proportional to the square root of the total number of phones. Average number of channels being routed through any given phone on the stripe is proportional to the square root of the total number of phones.
This holds as a fundamental limit regardless of the number of phones that any given phone can contact, and regardless of the routing algorithm.
Now do you see where I'm coming from?
Lastly, let's consider the assumption that you'd always be routing exclusively through other mobile nodes? Why?
Because that was what the article was suggesting be done.
If I'm allowed to use fixed towers, I'll just make them have as large a range as bandwidth lets me (to widen the stripe that things have to be routed through), and use very high capacity links between towers (so that high load isn't as serious a problem), and force all phone traffic to be routed through them. And maybe use something other than a mesh-style topology for tower-to-tower routing, if I have high enough capacity data conduits, as there's no range limit for tower-to-tower communication if I'm running fiber instead of broadcasting. But all of this dispenses of the idea of a magical phone-based decentralized network, which the article's authour was so enamoured with.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
That's only true if we assume a rectilinear grid, which I've already shown is ridiculous. For other topologies, you are - yet again - incorrect.
In your feeble mind, you mean. I just checked your previous post - cid #2389118 [slashdot.org] - and you offer no such definition of "node". It's an absurd definition anyway, which any reasonable person would reject.
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently. You get another "-1, Redundant" for that, kiddo.
Nope. Which planet would that be, again? What color are the skies there?
It doesn't matter, though. I don't care where you're coming from, but I know where you're going - my mental killfile. I give up; your resistance to reason is greater than my ability to explain what should be obvious.
Re:Scaling problems. Very nasty scaling problems. (Score:2)
That's no more rigorous than before. It's the same example and analysis that I already showed to be flawed, just worded a little differently.
Bushwa.
You're trying to make a call from phone A to phone B. The distance between the phones is an average of K times the range of phone-to-phone communication. How, pray tell, do you plan to do this in fewer than an average of K hops?
You have N phones, and O(N) calls. You have, therefore, O(KN) communications hops in total to service all calls. How, pray tell, do you plan to distribute O(KN) relays among O(N) phones without at least an average of O(K) relays being serviced per phone?
You have yet to provide a convincing argument (or any argument) against this. You seem hung up on me assuming a "rectilinear grid", which I did *not* do in my previous message.
I respond perfectly well to well-reasoned debate, and have admitted error many times in the past when presented with evidence or counterexamples. You have provided neither. Please do so.
Issues (Score:2, Insightful)
p2p Protocol - you do not want the situation where you broadcast to 5 other handsets around you and those broadcast out to "x" others...the target phone will get spammed. (ie, ACK - Thank you, I've received this message x 50 times) On the other hand, you do not want the situation where you relay on THE ONE closest mobile phone to act as your ONLY single relay point and so on....as if you do, probability statistic calculations show if (lets just say) 1/10 chance of failure per hop, this might not be acceptable in emergency situations.
Anyway, you might say "hey, but we could utilize timeouts, routing protocols (similar to RIP) etc etc etc", ......no matter what in the end, you will need to have
- more battery power
because you are constantly transmitting/receiving and processing on your mobile whether your mobile is in client mode or relay mode.You could also argue, you only use these features in emergencies situations. My idea would be for a telco to setup portable (and powerful) base station(s) (whether it be towers, or flexible cable antennas) around and in the emergency site.
Re:Issues (Score:1)
IETF MANET (Score:4, Informative)
http://www.ietf.org/html.charters/manet-charter
mod this up (Score:2)
And fix the link
http://www.ietf.org/html.charters/manet-charter.ht ml [ietf.org]
-Ben
Army interest (Re:IETF MANET) (Score:1)
You'll find that a lot of the research is funded by the army. They are very interested in these as a way to set up communications among an isolated troop in the middle of nowhere. They really want small non-power-hungry devices with multimedia capabilities that communicate in peer-to-peer fashion.
not feasible (Score:2, Insightful)
Yet more cancer? (Score:1)
Further more it would totally kill battery time. From the good part of a week on my 8210 to a mere few hours. And what about the bandwidth? 3G already has problems with getting the lousy extra bandwidth, and how much wouldn't be needed by this?
If we are talking extreme situations such as the WTC going up in smoke, I would think that keeping a few base stations for emergency situations would be a better idea, could be up really quick if you used choppers to lift them to the correct position.
Not to sound like a pessimistic but this doesn't sound especially thought through.
Been there done that...... (Score:1)
so instead of the suggested digital network you would create with SMS, instead you have a voice network where everyone could just talk to each other.
I am actually quite suprised more you havent heard of this feature of the Motorola cell phones.
~Wire
"Dont Quote Me" ~ anonymous
Re:Been there done that...... (Score:1, Interesting)
If so, I think you misunderstand what was happening. They were basically using a digital signalling technology to make it appear like a p2p network. Basically you were subscribed to a calling group, or had someone else's number programmed already, and whenever you pressed the Push-To-Talk button it just called up the receivers and they automatically answered - all in less than a second - and put it on the speakerphone.
sufficiently advanced technology == magic, etc.
This is more than a software upgrade (Score:1)
A couple of things (Score:2, Informative)
The first based on the way cellular systems work. The major cost of the system is centred in those parts of the network that are shared between the users, namely the base stations. This makes the handsets (which each user must have) cheaper and thus lowers the system cost by sharing the cost of the expensive parts between users. Great, but why is that relevant? It is relevant because the maximum range between a cell and a base station is primarily determined by the low noise (read: expensive) receiver and high power (read: expensive) transmitter at the base station. So the range of cell-to-cell communication will be MUCH less than the base station-to-cell range. So much so that it is possible that the distance between a cell that can see a base station and a cell that can't will be no more than a few metres. This means that a large number of hops will be required in most cases clogging up the system bandwidth and meaning that each cell will need to be able to store a large number of messages. These problems will be even worse in an emergency when everyone and their dog are sending messages. Also, cell-to-cell communication will require much more power from the cell than base station-to-cell communication because the reciever in a cell is not nearly as good as that in a base station.
The second problem has to do with battery life. The battery life of cell phones is rather short when the transmitter is used. As explained previously, the power needed for cell-to-cell communication is rather high, aggravating the problem. This could cause major problems when people's batteries start going flat because the person in the next office likes sending lots of messages and is out of range of a base station (quite possible in buildings).
I think this is a great suggestion, but it assumes that the cellular environment is the same as the internet, which it is not.
Bluetooth (Score:2, Interesting)
First you'd form a piconet. If any of the systems is physically connected to (internet | base station | something else), relay there, else form/connect next device on a (same | different) piconet (the next device might have different piconets available). When the working relay is found, send back a message, targetting the original device. Relay it randomly and add a node to the route table the message contains. The original sender can deduce a short path (it's not necessarily the shortest!) just by looking at the message that arrives first/has the shortest route.
At this point, it should be possible to send small text messages with some efficiency.
It's also possible for other devices that happen to recieve a route recovery message to use the some of the readymade routes (so that everyone doesn't need to do this slow procedure).
The total amount of transferrable payload *per device* should probably be limited to something like 2kB, if this is to be used as an emergency network, to insure everyone can transmit their messages.
Any ideas/corrections from those "in the know", especially bluetooth people here?
Disclaimer: I'm not a bluetooth specialist... In fact I don't know much at all about it! :)
Ad-Hoc routing protocols (Score:4, Informative)
Interested readers should probably read A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols [nec.com] to find out why this is difficult.
According to the article, phones would have to exchange and update their routing information all the time, even while everything was working normally (because by definition a phone can not know if a neighboring base station that's just out of reach is still working or not). Every phone would continuously keep broadcasting a list of every other phone and base station in it's reach.
This overhead alone (just to update the routing tables) would consume a big chunk of the bandwith all the time. Since a base station dropout or overload is an exception (hopefully), a dynamic on-demand routing protocol would make much more sense in this case.
What a great, innovative dea! (Score:1, Informative)
Oh but wait, maybe the army is not that bad after all:
http://www.mitre.org/pubs/edge/november_98/seco
and maybe there is something called ad-hoc networks. And maybe it's actually not that easy at all to implement in the real world:
http://citeseer.nj.nec.com/mcdonald99mobilityba
http://www.ee.cornell.edu/~haas/wnlprojects.htm
http://www.cs.ucla.edu/NRL/wireless/papers.html
http://nelson.www.media.mit.edu/people/nelson/r
Moral of the story. Not everything that is on O'reilly's website is gold. And for the author of the original article, he should really do some research before he claims he has a brand new idea that is "so cool..." he'll look less foolish next time!
Won't work due to RF sections (Score:2, Insightful)
The TX stage is totally designed to talk to the base station, and nobody else. That means it can only push low power (base station has big expensive high gain receive systems to extract signal from noise) and only at the TX frequency band.
Similary, the RX stage is designed to hear from the base station, and nobody else. That means it expects rather high power signals (base station is not running on batteries and can generate huge power if needed) and only at the RX frequency band.
This is the most fundamental part of RF network design -- do the small remote stations (handsets in this case) need to talk directly to each other, or just to a hub station (base in this case) that is equipped with a collosally more expensive array of equipment? THAT decision (and bitrates) drives ALL the remaining design decisions in the RF sections of both the remote and hub.
These kinds of things are fixed in hardware (e.g. capacitors and inductors, filters) and can't just be changed by downloading new firmware.
Nice but not a fault-tolerant solution (Score:1)
Cybiko cool 'toy' (Score:2)
a cool little device that i bought my niece for Xmas '00 was a Cybiko see Cybiko.com [cybiko.com]
The specs are here [cybiko.com]
With two units, one in the hand and one married to your PC the device will enable a limited sort of 'home wireless access' on WAP.
Who needs service fees and a monolithic oppressive corporate watcher, why not build a low power, low bandwidth network of peers in the 'cybiko fashion'.
..or wait till 802.11b(or 'a') chipsets become SUPER small and SUPER cheap...
Exactly! I want my super-Cybiko! (Score:2)
Another optimization-- you could design the network to prefer the shortest route to an internet gateway (any unit in its cradle hooked to a PC would be such a gateway), to move traffic off the relay network as soon as possible. This would allow much greater scaling and distance even in low-density areas.
If Cybiko can do it for less than $100, surely an industrial-strength one can be made for less than $700 or so-- which would be a deal considering there would never be a network fee!
Cheaper transceiver-only cards could enable existing laptops to access the network as well.
like Cybiko for adults, only less crappy! (Score:2)
If, say, a palm-pilotish device could be coupled with a cell-phone level transceiver (or possibly an FRS radio component for 2-5 mile range) we could have ad-hoc wireless wherever we go without paying network fees. In dense areas, the power could be lowered to prevent interference with all the other devices in the area, and internet bridges could help span large rural areas.
Is there anything preventing a company with no networking interests (they'd want monthly fees, then) from doing this?
this sort of exists (Score:3, Interesting)
Op with a 5 watt handheld has set up a small communication base near ground zero. The op can sync up with another op a few miles away and relay help and welfare information. Ground zero does not have power. The second op does not have power. The second op is able to relay the message to a ham with power who can relay the info on 20 meter to the other side of the country. With minimal amounts of planning and just a few hams, a system is devised that permits message relaying all over the country, even though the phone system is jammed and power is down for miles. Anyone with a decent scanner can pick up the signal on 20 meters and hear a nice formatted report of people who are OK.
Who pays for the text? (Score:1)
I make text message- I've got no reception so the text bounces off a few phones and ends up at a Fred's phone that has reception and sends it to the message centre. Does Fred pay the bill for that or do I?
Cell Phone D.O.S.?!? (Score:1)
Sounds cool but... (Score:1)
Will mobile operators give up an income stream? (Score:2, Insightful)
I come from Denmark, and yes we have a very useful and standardised network (sorry US). I think this new idea is really cool, but there is one major problem surrounding payment and the revenue streams for the mobile operators.
Today the mobile service providers have revenue on SMS messages. In Norway they overtax the SMS messages to have a really nice profit (up to more than one US$ pr message). In Denmark some government regulations have put a limit to the revenue/taxation on SMS messages.
What do this mean for the idea? If an SMS was being redirected from phone to phone, who would pay? If the last user (before the base station) should pay for all the massages he relays, I think he would choose other types of mobile phones. If the protocol contained the phone that sends the SMS, we would open up the network for hackers etc... Potentionally this type of network could render SMS completely out of their control, as an SMS message theoretically could move from phone to phone without touching a base station, pretty much like a message is being routed through the internet... (not completely like the internet, I know.)
And I don't think the mobile operators would give up their income stream.
Security (Score:1)
Another topic, this could be used (if widly excepted and implemented) to 'file share' those logos and ringtones everyone loves.
I don't know much about cellular technology, but those are the two ideas that came to my mind when I read the article.
Military solutions don't do well with civilians (Score:4, Interesting)
Re:Military solutions don't do well with civilians (Score:1)
Re:Military solutions don't do well with civilians (Score:1)
So would there be a chance of seeing an expensive corporate, short range solution for wireless p2p(or internet/freenet type stuff), within the next 5 years, and then slightly cheaper solutions until finally we all have phone chips in our wearables giving us chat, sms, statistics on population density and xml data on how late our train is?
When I saw the Cybiko site, suggested in the article as a simple embryonic version of this, the short range put me off, but if worked on, could provide maybe a secure (based on freenet?) information system for say, communicating between offices or from home, to do 24 hour support etc. Imagine if it supported ssh: wouldn't be good for hardcore stuff, but you could read a logfile from your bus, and advise on a solution.
Ok, excuse my little sysadmin dreams... 2008: still grumpy but stuck in transport with cool tech instead of stuck in a cubicle with the lusers themselves.
Ale
Nextel Service (Score:1)
the bad and the good. (Score:1)
Better solution (Score:1)
Is that the problem? (Score:1)
It's about time! (Score:2)
Of course my idea was for wireless P2P internet, not SMS, but the same basic principles apply.
TDD vs. FDD (Score:2, Informative)
Also, mobile phones get away with small antennas and relatively low power transmissions because the place they're talking to is usually a HUGE antenna sitting on top of a hill somewhere, high up or on top of a building. That system gives you reasonable cell size. If you had to have mobile to mobile it'd shrink the distance that you could send to quite considerably.
Finally, sad to say it but in North America you basically have 3 different and incompatible digital systems, in addition to the analog one. That'd cut down the possible intermediate hop hosts.
I'm not saying this is a bad idea but given the current cellular technology it is infeasible. Didn't the cell sites for the most part stay up in NY though? Heard on the radio this morning how there's been a huge increase in cell phone sales since then.
Opensource project already working on this.. (Score:2)
MP3 On The Train/Car (Score:1)
* sigh * (Score:1)
everybody wants to design cell phones (Score:1)
The base stations are plugged into the commercial power grid, so their transmitters and receivers are running all of the time.
However, handsets must conserve power, so instead of leaving the receiver on all of the time, they listen only at precisely-scheduled moments, synchronized with the base station's reference signal.
In order for this phone-to-phone relay system to work, the phones would either have to listen more often, or the sender would have to send at the time that the base station is normally sending. This would require some arbitration between the sender and the base station.
I'm not saying that this system is impossible. In fact, Japan has a system that uses a similar "repeater" technique for voice calls (handyphone? I can't remember). But what I am saying is that features like store-and-forward messaging were not considered important requirements when these protocols were designed. And retrofitting them onto existing standards would be costly, and would affect the performance of your handsets.
One final note on this. One might think that you could have a "relay mode" that the user could turn on and off, so you could decide whether to be an energy misor or a friendly relay. Today's handset user interfaces are already cluttered with a lot of crap that confuses the average (non-slashdot-reading) user. In general, this sort of user-selectable feature is discouraged. Instead, people just want to dial a number and talk. And they want a cool looking plastic case.
Solution for highly populated areas (Score:1)
For example on New Years eve 2001 I've been unable to place a call because to many people were using the local cells, and this technology would have allowed me to do it.
I don't see it as a technology very efective in rural areas or highways, and having current providers upgrade to this system won't happen.
This technology could create new local networks where instead of you having to pay for air time, you could just get away by buying a renewable encryption key.
Re:Beowulf cluster (Score:2)
/Brian