From Dengfanping, "in-depth understanding of ANDROID:WI-FI,NFC and GPs" chapter [excerpt]--seventh chapter in-depth understanding of Wi-Fi peer excerpt

Source: Internet
Author: User

The main contents of this chapter:
    • Introduce the Wi-Fi peer-to knowledge;
    • Describes the relevant code for Wifip2pservice, Wpa_supplicant in Android.
7.1 Overview

To undertake the 6th chapter introduction of WSC, this chapter will continue to introduce the Wi-Fi Alliance (Wi-Fi Alliance) introduced another important technical specifications Wi-Fi peer. The product name for this specification is Wi-Fi Direct, which enables multiple Wi-Fi devices to connect to each other without an AP.

Among the Wi-Fi related modules of the Android platform, the point of contact function is mainly focused on:

    • The Wifip2pservice in the Android framework, which functions like Wifiservice, is used for processing and peer-related work.
    • Wpa_supplicant-to-peer module in the

As with WSC, the analysis in this chapter intends to use the following methods:

    • First, we will introduce the basic knowledge of peer-to.
    • Then analyze the modules that are related to the peer, including settings, Wifip2pservice, and Wpas.

Now, let's get to know the peer.

7.2 Introduction to basic knowledge of peer

WFA defines a full-time peer agreement document with "Wi-Fi peer-to-peer Technical specification", with a current version of 1.1 and 160 pages in length. Peer technology enables multiple Wi-Fi devices to form a network without an AP (peer networks, also known as peer Group) and communicate with each other.

Wi-Fi peer technology is the basis for Wi-Fi Display (also known as Miracast, please refer to the author's blog post http://blog.csdn.net/innost/article/details/8474683). In the Miracast scenario, a smartphone that supports peers can connect directly to a smart TV that supports peers, and the smartphone then transmits its own screen, or media resources, to the TV to display or play. Obviously, the direct connection between Wi-Fi devices will greatly expand the use of Wi-Fi technology with peer-to-peer technology.

Note: According to the author's own judgment, with the support of more and more devices to support peer and Miracast, intelligent terminal equipment between the multi-screen sharing and interactive features will soon be realized. Also, at the time of writing this chapter, Google released Android 4.3. At the launch event, Google launched the Chromecast device. At present, the technical implementation details of Chromecast is unclear, it is said that Google's own definition of the Google Cast agreement (can refer to developers.google.com/cast).

Let's start with a brief introduction to the peer architecture.

7.2.1 Peer Architecture Introduction [1]

The three components are defined in the peer-to architecture, which I call a device, two roles. These three components are:

    • Peer device: It is the entity of the role in the peer-to-peer architecture that readers can think of as a Wi-Fi device.
    • Peer Group Owner:group Owner (GO) is a role that acts like an AP in infrastructure BSS.
    • Peer Client: Another role that acts like an STA in a infrastructure BSS.

I believe the reader of this book is not unfamiliar with the concept of these three components. In fact, peer-to technology mimics the structure of the infrastructure BSS network:

    • The smart terminal is a one-to-peer Device before the peer Group (that is, the peer Network) is formed.
    • Once the peer-to-peer negotiation between these devices is complete, there will be one and only one [1]device to play the role of Go (that is, to act as an AP) and the other device to play the role of client.

The final composition of this peer group organization is shown in structure 7-1:

Figure 7-1 Peer Group

Figure 7-1 shows the composition of a typical peer group, where:

    • Like a infrastructure BSS, there can only be one go in a peer group. A go can support 1 or more (that is, 1:n in the figure) clients connection.
    • Because go functions like an AP, the nearby STA that does not support peer-to-peer functionality can also be found and associated to go. These STA are called Legacy Clients.

Note: A more accurate definition of "do not support peer-to-peer" refers to the inability to process peer-to-peer protocols. Go is the same as the AP, so legacy Clients can also search for go and associate it with the peer network. However, because Legacy clients cannot handle peer-to-peer protocols, some of the unique features of peer-to legacy cannot be implemented in these clients.

The similarities between peer group and infrastructure BSS will be further discovered through the introduction of these readers:

    • When peer to peer group is built, it will first get security information through WSC.
    • The client then uses the negotiated security settings information to correlate the [2]go (AP in peer group).

In this section and infrastructure BSS, the STA uses WSC to negotiate security information and then associate the process to the AP exactly as before. It is this similarity that makes it possible for peer to make full use of some of the existing technical specifications. Figure 7-2 shows the technology that peers and their dependencies:

Figure 7-2-Peer and its dependent technology

The figure 7-2 shows that:

    • To ensure a certain rate of transmission, peer-to-peer device must support 802.11g and above specifications. Among them, the security section must support WPA2. Because one of the main applications of peer-to-peer technology is to share media data between devices (for example, the Miracast scenario mentioned earlier), peer-to-device must also support WMM (a Wi-Fi multimedia abbreviation, It is a QoS service originating from 802.11e, primarily for the transmission of real-time AV data.
    • Before the peer client is associated to go, the security information needs to be negotiated through WSC, so WSC is also a peer-dependent technology item.
    • On the basis of the above technology, the peer-to specification defines a number of unique technical items, figure 7-2 lists three of the technologies that must be implemented, which are peer-to Discovery, peer Group operation, and peer Powermanagerment. In addition to these three required technology items, the peer specification defines an optional technology item called managed peer device operation, which defines how to configure and manage peer devices uniformly by the corresponding IT department in an enterprise environment.

Among the technology items shown in 7-2, Peer discovery is unique to peers and is also at the heart of it. This chapter will focus on it. First look at Peer Discovery.

Tips:

1. Peer group operation is about how go manages a group, that is, the job responsibilities of go. This part of the content invites the reader to study reference [2] on their own.

2. Peer-to powermanagement and power management of peer devices, to save unnecessary power loss. Because of the space relationship, this chapter does not intend to discuss it. [3] Ask interested readers to learn reference materials on their own.

7.2.2 Peer Discovery Introduction [4]

The purpose of peer-to discovery is simple, which is to enable multiple peer device to discover each other and build a group. According to the specification, it consists of four main technical sub-items:

    • Device Discovery: Used to search for peer-to-peer devices around peers.
    • Service Discovery: Based on this device Discovery, peer also supports searching for specified services. This part of the feature is optional, I think it and the second chapter 2.2.5.1 "Apple Bonjour Technology Introduction" mentioned in the Bonjour similar.
    • Group formation: Used to determine the two-peer device who plays the go and who plays the client.
    • Peer invitation: Used to activate a persistent group (explained below), or to invite a client to join a group that currently exists.

Hint: Group persistent (permanent) group and Temporary (temporary) group of two kinds. Let's give two simple examples to illustrate the difference between the two:

Temporary group: When you have a document to pass to a colleague, both sides turn on the Wi-Fi peer-to feature of the phone, set up a Group, transfer the file, and finally turn off Wi-Fi peer. In this process, the role assignment of go and client is determined by group formation, this time go may be your device, and next time it may be someone else's device. For this group, the security configuration information involved in establishing the group and the information related to group (which we will see later) are temporary, i.e. the security configuration information will change the next time the group is assembled.

Persistent group: In this group, go is played by the specified device, and once the security configuration information and Group related information is generated, subsequent changes will no longer occur (unless the user is reset). Go in persistent group is seen in fixed-purpose devices such as printers. So, in addition to the first time to connect to the printer with a little bit more trouble (need to use WSC to negotiate security configuration information), subsequent use, because the peer-to the device will save the security information, so the next time you use the printer can be used to directly associated with the printer.

Due to the space relationship, this chapter will only cover the most basic device discovery and group formation of the four knowledge points mentioned above, and the content of service discovery and peer invitation should be read through this chapter before reading the peer specification.

1. Peer Device Discovery Introduction

Peer device discovery, while also using the 802.11 probe request and probe response frames to search for peripheral devices, is more complex than the wireless network search in infrastructure BSS. To give a simple example, a peer device will have to receive probe request frames from other devices and reply to probe response frames, in addition to sending probe request frames themselves. In infrastructure BSS, only the AP sends probe response frames.

To speed up the search, peer-to discovery has defined two states and two stages for device.

(1) Device Discovery Workflow Introduction

The workflow of peer-to-Device discovery consists of two states and two stages. Let's take a look at two states, respectively:

    • Search state: In this status, the peer device will send the probe request frame separately on the 2.4GHz 1,6,11 band. These bands are called Social Channels. To differentiate between non-peer probe request frames, the peer Device Discovery requires that peer IE be included in the probe request frame.
    • Listen state: The peer device will randomly select a band in the 1,6,11 band (the selected band is called Listen Channel) to listen for probe request frames and reply to probe response frames. It is worth pointing out that once the Listen channel is selected, it cannot be changed throughout the peer-to discovery phase. In addition, at this stage, the peer device handles only those probe request frames that contain peer-to-peer IE information.

Let's look at two more stages, namely:

    • Scan Phase: scanning phase. This phase, like the wireless network scan described in the previous section, sends the probe request frame (active scan) on each band. Peer device does not process probe request frames from other devices during this phase. After this phase, the peer device will go to the next stage, the Find Phase.
    • Find Phase: Although from Chinese translation, scan and find mean closer, but the peer to find Phase and scan Phase very different. During this phase, the peer device will switch back and forth between search state and listen state. In Search state, the peer device sends the probe request frame, and in listen state it receives the probe request frame of the other device and replies to the probe response frame.

Figure 7-3 shows the process of peer-to discovery.

Figure 7-3 Peer Device discovery process

Figure 7-3 shows the discovery process for two peer-to-device, where:

    • After the discovery is started, device first enters scan Phase. At this stage, the peer device sends a probe request frame on all of its supported bands.
    • When Scan Phase is complete, device enters find Phase. In this phase, device will switch between listen and search state. According to the previous introduction, the Listen channel for each device was determined before discovery began. For example, the Listen channel for device 1 in Figure 7-3 is 1, while the Listen channel for device 2 is 6.
    • In Find phase, the peer specification has a requirement for the time that the device is in listen state, which is an integer multiple of 100TU, and the value of the multiplier is a random number. Located between Mindiscoverableinterval and Maxdiscoverableinterval. These two values default to 1 and 3, and the vendor can modify them. The reason for choosing a random multiplier is to prevent two device from entering the so-called Lock-step Circle, which means that two device simultaneously enters listen state, waiting for the same time and then entering search state simultaneously. This way, neither side can handle the probe request information (in Search state, device only sends probe request). In Figure 7-3, Device 1 First listen in the state of 2 100TU, and the second time in Listen State 1 100TU.
    • When the device is in search state in Find phase, it sends the probe request frame on the 1,6,11 band. Note that only when two devices are in the same band can a party send a frame to be received by the other.

Tip: The peer-to spec has a very detailed description of the two states and two stages, and even a detailed description of what each state can and cannot do. However, from the point of view of how to quickly master the peer-to frame, I think these content is too verbose.

Once you understand the general workflow of device discovery, we'll look at the probe request and probe response frames used by peers using the examples below.


[1] Assume that the device will only be composed of one peer Network.

[2] Note that the association here refers to RSNA, whose workflow includes including 4-wayhandshake.

Android Wi-Fi Display (Miracast) Introduction

http://blog.csdn.net/innost/article/details/8474683

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.