If you had to start from scratch which wireless protocol would you pick？

--转载技术牛人写的文章,与大家分享!
If you had to start from scratch which wireless protocol would you pick？
Hi All,

It's important to contextualise the topic so that it's not too broad when discussing the best solution. Indeed, I'm aware that most wireless protocols, from the smallest and lightest to the most sophisticated and complex have their relevant strengths and weaknesses. So, let me provide a context and see where we end up...

I'm investigating a protocol that can be used for low-bandwidth signalling and telemetry typical of WSN type applications. In particular, I suspect the protocol will be used in home automation applications, but I don't want to constrain it to such a small and specific application subset. While home automation will be predominantly applicable, I'd like a protocol that would ideally be interoperable with smart grids, but at very least should be conversant with smart energy and energy monitoring standards (if any even exist at this stage - Zigbee's Smart Energy profile is the only one I'm vaguely aware of, and I believe things may be changing here). Signalling and telemetry is obviously critically important, but it would be great if a protocol was available that supported compressed audio streams (they needn't be standards based streams like mp3). I'd be happy if the bandwidth was sufficient to transmit low-quality audio streams with acceptable latency delays (acceptable from a human perception perspective) for bidirectional speech.

Broadly speaking that sets the application stage. More technically, low-power is a definite requirement. However, not all of them need to be battery powered. I'm happy to support a combination of battery and mains-powered nodes. First prize would go to the protocol that supports battery-less nodes, although I'm led to believe that EnOcean pretty much has that under lock and key. I'd like a protocol that can seamlessly move from a beacon mode of operation to a non-beacon mode of operation. I see application for both modes of operation. One where more real-time high-bandwidth response is required; and one where low-power, event and life-support signalling is required. The concept of mesh networking is important. In other words support for multi-path signalling with self healing capability. In addition, I like the idea of meshed networks because they overcome the often encountered range restrictions that end-node to end-node topologies suffer from. The exact implementation of the mesh network is not of critical importance, so long as the benefits I've discussed are satisfied. While on the topic, another important technical requirement is for nodes that move out of range of the network, rejoin the network immediately the instant they move back within range (and signal the network, or are signalled by the network).

On top of the requirements discussed above, I believe the following things are also important or will help to contextualise the topic:

I have a strong belief that any serious commitment to a WSN protocol requires that the protocol is standards based. Furthermore, the standard should be as open as possible. In this regard 6LoWPAN is probably best of breed. I like Zigbee, but it does worry me that it is not as open, nor quite as non-profit as 6LoWPAN. The adopter fee of something like $3500 (not sure if that is an annual fee) is certainly a concern. Still maybe the fee is a good thing as it means that the alliance can better maintain and provide future support. In either of the above two cases, namely 6LoWPAN or Zigbee, their strength lies in their broad based standardisation. I worry about protocols like Z-Wave, MiWi, DASH7, EnOcean because they are fairly proprietary, or they are run by companies that treat the protocols as a direct source of revenue (EnOcean, for example).

I believe that application profile support is important. Zigbee seems to be streets ahead in this regard. Why is this important？ So that two manufacturers, that don't know one another from a bar of soap, can develop product lines that are truly interoperable. Lack of standards based application profiles, means that every developer creates their own proprietary signalling API; and that can't be good for the industry, or more importantly, for the consumer.

What about the correct protocol from a RF frequency perspective？ 433MHz, 868MHz, 915MHz, 2.4GHz？ I have some thoughts here. 433, 868, and 915 worry me because they are not recognised as standard bands for WSN applications in different regions around the world. Additionally 433 and 868 are typically fairly congested networks. I live in South Africa, and can speak with some authority when I say that the 433MHz ISM band is swamped with non-compliant radio transmissions. Our regulatory body ICASA has little to no chance of cleaning up this band and making sure that everyone plays nicely with everyone else. With these two issues as major limitations, only 2.4GHz remains. Also heavily congested, but the radio signals are well controlled and the equipment that operates at these frequencies far more compliant. The only downside as I see, is the significant absorption losses at these frequencies.

I have not discussed the number of nodes or the number of hops that are allowed from one node to another. The reason is because these numbers should be big enough that, to all intents and purposes, they are in no way restrictive. So what are we talking about？ Maybe 65k nodes in a network, and a minimum of 30 hops from end to end. Any protocol that is significantly more restrictive than this should probably be discarded.

The network must intrinsically support fairly robust communication. This means that acknowledged communication must be supported within the protocol stack. Best case would be for a protocol to support both acknowledged and unacknowledged messages. Importantly it is the protocol itself that must support this functionality. I think supporting acknowledged frames at the application layer places too much of a burden on the application and the application developer. This is a communication related concern, and therefore should be a protocol related abstraction.

Of all the above issues, probably the most important thing is for the selected protocol to stand the test of time. It should be the most widely adopted protocol for WSN applications. Who will win the war？ I have no idea and that is why I am posing the question. If you experts out in the field had to select the protocol that you believe (based on the outlined requirements and use them loosely - don't let one failed requirement spoil the protocol) will stand head and shoulders above the rest, which one would it be？ If so, why？ What are your reasons for selecting it？
Enter code here
Please note, although no boardcode and smiley buttons are shown, they are still useable