[转载]一篇非常好的文章：wifi-direct对比ad hoc 无线网络

Posted On 2015年6月8日

Why Wi-Fi Direct can not replace Ad-hoc mode

Wi-Fi Direct vs Ad-hoc mode

In this article we describe the basics of Wi-Fi Direct (“P2P”), point out the differences to Ad-hoc (“IBSS”) mode and explain why Wi-Fi Direct can not substitute Ad-hoc mode.

Both, Ad-hoc mode and Wi-Fi Direct allow devices to connect directly to each other in a peer-to-peer way, without the use of a traditional Access Point. While Wi-Fi Direct is marketed as a replacement of Ad-hoc mode, and is claimed to be “much more secure” and easier to set up, it does not cover all possibilities of Ad-hoc mode: most importantly the capability to form larger-scale networks. And it comes at the cost of more complexity and only works well in limited situations. But let’s have a look on both protocols first.

What is Wi-Fi Direct (P2P)?

Wi-Fi Direct™ is not an IEEE standard, but a Wi-Fi Alliance technical specification called “Wi-Fi Peer-to-Peer (P2P) Specification”. It allows Wi-Fi devices to connect to each other and form groups, usually one-to-one, but also one-to-many. Wi-Fi Direct devices negotiate their roles in the connection: one of them assumes the traditional role of Access Point (AP) called Group Owner (GO) and the other devices, including non-Wi-Fi Direct enabled devices, connect to the AP/GO as clients in station mode. While we will argue below that this is not true peer-to-peer in the usual meaning of the phrase, we follow the term “P2P” as it is used in the specification in the rest of this description.

Wi-Fi Direct has some minimal requirements like the use of 802.11g, RSN (WPA2) with AES-CCMP encryption, Wi-Fi Protected Setup (WPS), WME (WMM) quality of service, and OFDM data rates for management frames. P2P devices use their global MAC address asDevice ID during discovery and negotiation, and a temporary local MAC address for all frames within a group. Action frames and additional Information Elements (IE) are used to transport the details of the protocol.

1) Device discovery

Before any connection can be formed, P2P devices have to find each other. For this they alternately listen and send probe requestswith additional P2P information elements on so-called social channels, which are channels 1, 6 and 11 in the 2.4GHz band. Unconnected P2P devices and Group Owners reply to them with probe response frames which also include P2P information elementsdescribing the device and group characteristics. Group Owners respond in place of devices which are part of their group, but clients may choose not be be discoverable while they are connected to a group.

Device characteristics include:

• User-defined device name (e.g. “My Printer”)
• Device type (e.g. “Media Server”, “Smartphone”, “Television”, “Printer”)
• Supported WPS configuration methods (PIN, or PushButton)
• Supported operating channels
• Are additional connections supported?
• Is service discovery supported?

Group characteristics include:

• Can more devices join the group (group-limit)?
• Is data exchange between clients provided? If yes, a device may join the group to communicate with any of the devices in the group (intra-BSS)
• Does GO provide a connection to another WLAN or the Internet (cross-connection)?
• Is this a persistent group?

2) Service discovery

After a P2P device has been discovered, and before establishing a group with it, it can be asked to describe the services it provides. This is an optional frame exchange which supports different service description protocols, such as “Bonjour” (DNS-SD), UPnP orWS-Discovery. After that, the application or user may choose to connect to a device based on its name or provided services, e.g. a camera may automatically connect to a display to show its photos, or a user may choose to connect to “My Printer” to print a document.

3) Group formation

If a device wants to connect to another, it can send a P2P Invitation request to a device which is already connected to ask it to join a new group, or it can directly start the formation of a group with an otherwise unconnected device by sending a GO Negotiation request.

Any P2P device can take the role of P2P Group Owner (GO) or P2P Client but the roles in the group are negotiated. The main purpose of this negotiation is to determine which of the two participating devices will become the GO and to exchange some characteristics of the group, like the operating channel, the WPS configuration method, and whether the group is a persistentgroup. Devices can communicate their willingness to become group owner with the GO Intent attribute (0-15) of the GO Negotiation request/response frames, and may refuse to form a group if the parameters of the group are not acceptable. By specification, group formation should be completed in less than 15 seconds, but since normally the user is required to enter a PIN code, or push a button, it can take more time.

After the decision has been made which device will become the Group Owner, a GO Negotiation confirmation is sent and both devices move to the negotiated operating channel. The GO starts to operate in Access Point mode, sending beacons with the negotiated SSID and a group formation bit set to 1, because the group formation has not yet been completed. The SSID is standardized to be “DIRECT-xy…” with xy being random characters/numbers and any postfix.

4) Provisioning and Encryption

Now the provisioning phase begins, where the client connects to the GO to exchange credentials with the WPS protocol, which is an exchange of eight EAP messages. To allow the connection, the user normally has to enter a PIN code or push a button on the device.

When joining an existing group, or to speed up the provisioning phase later, devices can send Provision Discovery request/response frames before starting the group negotiation. If not, the GO Negotiation may fail and have to be restarted when the user has taken more time than expected.

After that, the normal RSN (WPA2) 4-way handshake begins to exchange the encryption keys, where the GO assumes the role ofauthenticator and the client is the supplicant. Then the client will request a IPv4 address from the GO, which is required to implement an DHCP server, and finally actual data transfer can happen.

To avoid users having to enter a PIN code every time when a group is formed regularly between some devices, the group can be made persistent, in which case the devices  store the credentials and can automatically re-connect when required. A persistent group may use a different channel and device MAC addresses for each session.

4) Power Management

Wi-Fi Direct also describes some extensions to the 802.11 and WME power management: Opportunistic Power Save (OppPS) allows the GO to sleep in periods where all clients are in Power Save mode. Also the GO may send a Notice of Absence (NoA) in its beacons or in direct action frames to announce the fact that it will be absent for some period of time because it is sleeping or doing some work on another channel. Clients which have important traffic or specific delay requirements can send a P2P Presence Requestto its GO which may or may not adapt its power save behavior.

5) Optional features: Concurrent operation and Manageability

The P2P specification mentions that P2P devices may support concurrent operation as multiple MAC entities, possibly on different channels, and thus could be part of more than one P2P group or WLAN simultaneously, but it does not further describe this option. We assume that current (2013) Wi-Fi chipsets may support two concurrent connections at the time, possibly more later.

Another optional feature of Wi-Fi Direct is the manageability of P2P devices in enterprise environments. The managed enterprise AP has the possibility to restrict P2P devices in its vicinity by limiting their allowed channels or transmit power and it can also disallow them to provide cross-connections into the corporate WLAN.

6) Frame exchange sequence

Now, let’s look at an example frame exchange, where two Wi-Fi Direct devices “A” and “B” are discovering each other and form a group… Wi-Fi Direct supports many different scenarios, but we assume that this is the most common case.

At first both devices will enter the scan phase, and send

A B (1) Probe requests with P2P IE on all channels.

After a random time one of them will start to listen on one of the social channels (1, 6 or 11) and finally receive a probe request from the other station. It will reply with:

A B (2) Probe response with P2P IE

Device A reports “Another device found” to the user or managing application. Now an optional service discovery exchange can happen:

A B (a) Service Discovery query
A B (b) Service Discovery response

We don’t count this optional frame exchange to have a fair comparison to Ad-hoc mode later.

Then group formation begins:

A B (3) GO Negotiation request

B reports this to the user and will wait for the input, which we assume to timeout in this case.

A B (4) GO Negotiation response (fail)

Optionally, instead of having the first GO Negotiation fail, the devices could have used Provision Discovery before group formation, but this does not change the number of total frames exchanged:

A B (3) Provision Discovery request
A B (4) Provision Discovery response

A B (5) GO Negotiation request

In the end we suppose the user on B has allowed the connection.

A B (6) GO Negotiation response (success)
A B (7) GO Negotiation confirmation

Now one device becomes GO and the other client, Let’s assume B is the GO

A B (8) GO sends beacons (formation bit = 1)
A B (9) Authentication 1
A B (10) Authentication 2
A B (11) Association request
A B (12) Association response

Now the “provisioning” phase begins, which is a WPS exchange of usually 8 frames. We don’t go into the details of the WPSprotocol here.

(13) (14) (15) (16) (17) (18) (19) (20)

Next the GO starts to send beacons with the formation bit set to 0.

A B (21) GO beacon (formation bit = 0)

The client re-authenticates and re-associates with the new credentials:

A B (22) Authentication 1
A B (23) Authentication 2
A B (24) Association request
A B (25) Association response

Now the RSN 4-way handshake begins, and again we don’t go into the details of RSN:

A B (26) ANonce
A B (27) SNonce + MIC
A B (28) GTK + MIC
A B (29) ACK

After that we can exchange data frames in the group, but usually the DHCP protocol will be used first to provide the client with an IP address. Again, we don’t count these frames to have a better comparison to Ad-hoc mode.

At least 29 frames had to be exchanged before the first data transmission. In the case of two devices re-invoking a persistent group, we need at least 18 frames.

Ad-hoc (IBSS) mode

Ad-hoc mode is officially called IBSS (Independent Basic Service Set) in the IEEE 802.11 standard, and contrary to what some people believe is neither “legacy” nor inherently insecure – it’s an active part of the current IEEE802.11-2012 standard, which states that “IBSS is the most basic type of IEEE 802.11 LAN“. All standard-compliant devices should implement it. In comparison to Wi-Fi Direct, IBSS mode is very simple, but let’s recapitulate how IBSS mode functions:

1) Ad-hoc network formation

Any device can start an IBSS, and there is no hierarchy between IBSS devices, which is why we usually call an IBSS device just “node“.

A device wishing to join an IBSS with a certain name (SSID) will scan to see if the network already exists, by passively listening on the channel and receiving beacons from other nodes or by sending probe requests. If an existing IBSS is detected its BSSID is taken over and data frames can be exchanged directly between all IBSS nodes within radio reach.

2) Beaconing

Just as APs, IBSS nodes regularly send beacons, containing the network name (SSID), a BSSID and a timer value (TSF) to announce the existence of the IBSS network. In order to save bandwidth, devices in the same IBSS share the task of sending beacons: if a node already received a beacon from another device within one beacon period, it will itself refrain from sending a beacon this period. Random back-off intervals ensure that every device gets its chance to send a beacon every once in a while. In order to be backwards-compatible to 802.11b, the beacons and management frames are sent at low data rates (1 or 2 Mbps) by default, but any good driver implementation will let us choose the basic rates so we can also use only OFDM rates just as Wi-Fi Direct.

3) IBSS merge

There is only one tricky case in IBSS mode, which is called “IBSS merge” or “IBSS coalescing”, which is when two or more nodes with the same network name (SSID) have previously chosen different BSSIDs, possibly because they were not within reach of each other, but now they are joining. You can imagine a group of inter-connected smartphones coming into a room where another group of devices is using the same IBSS. In this case, the rule is that the “younger” IBSS has to take over the BSSID of the “older” IBSS. The age of an IBSS is know by the TSF timer values sent in the beacons. This rule is described in the 802.11 standard but it takes some reading between the lines to figure out how to properly implement it, and this is the reason why some drivers and firmwares have had problems with IBSS mode in the past.

4) Security

There is no standard requirement for security in IBSS mode, so IBSS networks are free to choose between using no encryption,WEP, WPA or RSN (WPA2). So, same as APs and Wi-Fi Direct, Ad-hoc mode can also be used with RSN (WPA2) pre-shared keys, although support for this has just been added recently in Linux. For exchanging the encryption keys, all IBSS devices have to make the 4-way handshake between each other.

It is not uncommon for some Ad-hoc networks, like community or disaster recovery networks to use no encryption on the network layer, leaving it to higher layers (for example OpenVPN or the application protocol) to implement encryption when desired.

5) Frame exchange sequence for an IBSS with RSN

Let’s look at the frame exchange sequence of two nodes forming an IBSS which is using IBSS-RSN to provide RSN encryption and thus the same level of security as a Wi-Fi Direct group.

First, the joining device may scan to find an already existing IBSS:

A B (1) Probe request
A B (2) Probe response

Then open authentication may be used:

A B (3) Authentication (open)
A B (4) Authentication (open)

After that we see the RSN key exchange from A to B:

A B (5) ANonce
A B (6) SNonce + MIC
A B (7) GTK + MIC
A B (8) ACK

And then the key exchange in the other direction:

A B (9) ANonce
A B (10) SNonce + MIC
A B (11) GTK + MIC
A B (12) ACK

In this case we had to exchange 12 frames before actual data traffic can be exchanged. If encryption is not used, we can exchange data right away, after receiving a probe response or beacon from the other node, as the authentication and probe request frames are optional.

Depending on the setup of the Ad-hoc network, DHCP can be used to provide IP addresses, but due to its distributed nature Ad-hoc networks are usually configured with static IP addresses, IPv6 or other by methods.

Topology scenarios

Let’s play through some topology examples, in scenarios where Wi-Fi Direct is targeted and marketed. We assume that the involved Wi-Fi Direct devices do not support concurrent operation.

1) Home media center

Let’s say I have the latest Wi-Fi Direct enabled Miracast™ television in my living room, and I connect my smartphone to it to control the content shown. The video I am watching is streamed to the TV from a media server or NAS which is connected to the same Wi-Fi Direct group. As it happens, the smartphone can not directly see the media server and the TV is the group owner.

Now, someone else in another room wants to connect to the media server to view some photos on a tablet. Unfortunately the tablet is too far away from the TV, so it can not just simply join the existing group (if the TV allowed intra-BSS traffic it would exchange data on behalf of the tablet and media server).

Now we have two options, both of which lead to a fragmented network and an unpleasant user experience:

a) The tablet sends an P2P Invitation to the media server, but it refuses to join another group, since it is already connected to the TV. The tablet can not connect and see the photos.

b) The tablet sends an P2P Invitation to the media server and the server chooses to form a new group with the tablet where it ends up being the GO. The TV could try to re-negotiate its group membership with the new GO to resume the video stream, after a half-minute delay, if at all possible (the TV may require to be GO).

The smartphone is locked out of the group and can not enjoy the benefits of Miracast™ any more.

Ad-hoc mode

In the case of an Ad-hoc network, the tablet would be able to connect to the media server independently of the other devices, obviously having to share the available bandwidth at the server with the ongoing video stream to the TV. All participants could enjoy the desired functionality.

2) Mobility

Another problematic case for Wi-Fi Direct is mobility or when the GO disappears. Then, the group has to be re-negotiated and this will lead to service disruption if devices are using the connection at the moment. Also as we have seen earlier each group negotiation is approximately 29 frames, which can require a lot of bandwidth, especially with interference, lost frames and many retries, which is usually the case in highly mobile scenarios.

Let’s consider the following example, and let’s assume that the devices always try to maintain a connection, for example because they use the Internet cross-connection, or because some higher-level protocol wants to exchange data between all devices.

Again, let’s assume I am at home, connected to my modern Wi-Fi Direct TV which is GO, provides me with Internet and also a connection between my smartphone and the smartphone of my wife, which we use to exchange a large amount of holiday photos.

While the synchronization happens, we realize that we forgot something in the car, and move there with both phones. After leaving the house the GO is not in reach, so the smartphones have to negotiate a new group between each other, in the attempt to keep synchronizing. That will take some time and unfortunately may configure different IP addresses than before, which applications usually don’t react to well.

Now, at the car, a persistent Wi-Fi Direct connection to the cars navigation system is re-invoked for both phones, again resulting in group negotiation frames, different IPs and the loss of the application connection.

On the way back, the same thing happens again, and basically we have to re-start the photo synchronization many times.

Ad-hoc mode

In the case of Ad-hoc mode, no connections have to be negotiated and data can be exchanged just as the radio transmission allows, so as they move together, the two smartphones could always keep synchronizing. When the TV or car is in reach its services could be used without requiring re-configuration of the smartphones.

3) Other scenarios

While the examples above might seem artificial, we can imagine many similar or more complex situations where Wi-Fi Direct does not work well. We know from experience that any problematic topology will happen at some point and that the frame exchanges caused by many re-configurations can eat up the limited available bandwidth quickly. Also interference or moving objects can cause mobility scenarios even though the devices are static, which means that groups may have to be re-negotiated frequently as devices come and go into each others reach. This can disrupt the service as we have seen above, and while that may be annoying but acceptable to some extent for personal usage, it is usually not acceptable in more critical or business applications.

If the Wi-Fi Direct devices would support concurrent operation, they could solve the topology scenarios described above, but fail at more complex ones – independently of the number of possible concurrent connections there will always be some limit and some topology which can not be supported. Also concurrency can not solve the problem of topology changes and the resulting re-negotiations of groups which can cause service disruption, which we believe may be the worst problem of Wi-Fi Direct from a usability point of view.

Comparison between Wi-Fi Direct (P2P) and Ad-hoc (IBSS) mode

If we take the definition of peer-to-peer (P2P) which is “Peers are equally privileged, equipotent participants in the application” we have to conclude that Wi-Fi Direct, despite its name “P2P”, is not a real peer-to-peer protocol. It is essentially a protocol for forming hierarchical groups, and mostly used to connect just two devices. The devices are only equal peers until they connect to each other, and one of them becomes group owner. After that they follow the hierarchical roles of AP and client – master and slave. While the protocol, especially in combination with service discovery can provide a convenient and secure way to temporarily connect two devices, like a camera to a printer, it does not scale beyond a few devices in close proximity.

On the other hand, the comparatively old, simple, and often neglected Ad-hoc (IBSS) mode is a true peer-to-peer solution with no hierarchies, where all participants are equal. This opens up a wide range of possibilities and communication modes, among themopportunistic, delay-tolerant networking and large-scale mesh networks, which are especially useful in scenarios where local infrastructure is untrusted or unavailable. But because IBSS mode is so simple and has many configuration options, it can be difficult to use. Even though we have shown examples where plain IBSS mode has advantages over Wi-Fi Direct in some application-scenarios, it can show its real strength only in combination with higher-layer protocols which implement IP allocation, service discovery, encryption, and possibly multi-hop forwarding.

Benefits of Wi-Fi Direct Easy to use for temporarily connecting a few devices Security and encryption is built into the protocol Service discovery is part of the protocol, although optional		Benefits of Ad-hoc mode Real peer-to-peer solution Can handle dynamic topology changes Enables large-scale mesh networks Simple protocol No extra frames need to be exchanged before data traffic
Drawbacks of Wi-Fi Direct Some topologies are not supported Does not respond well to dynamic topology changes Complex protocol Many frames need to be exchanged before data traffic		Drawbacks of Ad-hoc mode Difficult to use for unexperienced users All nodes in the network are on the same channel No built-in security or encryption No built-in service discovery

Conclusion

Finally we conclude that Wi-Fi Direct and Ad-hoc mode solve very different use-cases and one can not replace the other. Wi-Fi direct is made for temporarily connecting a few devices in an easy-to-use and secure way, but it does not work well for larger network topologies. IBSS mode is more versatile and difficult to set up, but can be used together with higher level protocols to form large-scale mesh networks. To use the term peer-to-peer equally for both solutions is misleading since it leads to the assumption that the limited form of “P2P” of Wi-Fi Direct could substitute the real P2P capability of Ad-hoc mode, which is not the case.

此篇文章已被阅读7931 次