The disclosed embodiments relate to channel assignments among the members of one or more peer-to-peer (P2P) groups, e.g., in a Wi-Fi Direct arrangement.
The increasing ubiquity of personal wireless devices has generated increasing pressure to use scarce bandwidth resources efficiently. For example, the Wi-Fi™ Display and Wi-Fi™ Direct standards permit devices to be arranged in a Peer-to-Peer (P2P) group so as to effectively coordinate their transmissions. One member of the P2P group, designated the “group owner”, may coordinate communications among the other “peer” or “client” devices of the group. Unfortunately, not all the members of the group may have the same or similar resource demands. For example, one device may be involved in a data intensive Voice Over IP (VOIP) transaction or Wi-Fi™ Display video stream, while another device may perform only periodic webpage refreshes. The changing channel quality in different environments, at different times, and in different frequencies, further complicates the situation. While the P2P group owner may wish to reallocate channel resources to accommodate the bandwidth intensive devices, an efficient method under the P2P standard for doing so may not be available.
The techniques introduced here may be better understood by referring to the following Detailed Description in conjunction with the accompanying drawings, in which like reference numerals indicate identical or functionally similar elements:
While the flow and sequence diagrams presented herein show an organization designed to make them more comprehensible by a human reader, those skilled in the art will appreciate that actual data structures used to store this information may differ from what is shown, in that they, for example, may be organized in a different manner; may contain more or less information than shown; may be compressed and/or encrypted; etc.
The headings provided herein are for convenience only and do not necessarily affect the scope or meaning of the claimed embodiments. Further, the drawings have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be expanded or reduced to help improve the understanding of the embodiments. Similarly, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments. Moreover, while the various embodiments are amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the particular embodiments described. On the contrary, the embodiments are intended to cover all modifications, equivalents, and alternatives falling within the scope of the disclosed embodiments as defined by the appended claims.
Various examples of the disclosed techniques will now be described in further detail. The following description provides specific details for a thorough understanding and enabling description of these examples. One skilled in the relevant art will understand, however, that the techniques discussed herein may be practiced without many of these details. Likewise, one skilled in the relevant art will also understand that the techniques can include many other obvious features not described in detail herein. Additionally, some well-known structures or functions may not be shown or described in detail below, so as to avoid unnecessarily obscuring the relevant description.
The terminology used below is to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific examples of the embodiments. Indeed, certain terms may even be emphasized below; however, any terminology intended to be interpreted in any restricted manner will be overtly and specifically defined as such in this section.
Overview—Channel Reassignment with Group Retention
Various embodiments include protocols and algorithms for selectively transitioning peers in a P2P group, e.g., less than all the peers in the group, from a first channel to a second channel. The group owner may consider: which peers are in communication; the quality of an existing channel link with the peers; and the quality of an alternative channel. The alternative channel may have been identified actively or passively during the search and scan processes used to establish the group. When a transition is to occur, a modified channel switch announcement message identifying individual MAC addresses for transition may be used to effect the transition. Measurement of the peer-to-peer link quality may be accomplished using standard 802.11 measurement request primitives.
As all of the client devices are communicating on the same channel (Channel 1), it may be difficult or impossible for each to achieve its desired operational behavior. For example, where one of the client devices is engaged in a voice-over-IP (VOIP) operation, the client device may compete for bandwidth with another client device. Devices 120c and 120d may be communicating directly with one another within Channel 1 across the connection 115d. The connection 115d may be, e.g., a TDLS link, or may reflect continual communication between devices 120c and 120d through group owner 120a.
Accordingly, various embodiments transition 105 each of connections 115b-d from Channel 1 to Channel 2, so as to achieve a second configuration 100b. Each of the connections 115b, 115c and 115d may now occur on Channel 2, thereby alleviating congestion on Channel 1.
Channel Reassignment without Group Retention
When deciding which channels to select and whether to form new groups as described in
FIG. 3 is a timeline showing steps in the scan and search phases of P2P device discovery as implemented in some embodiments. Although alternative channels may be identified at various points as discussed herein, in some embodiments a device anticipating its role as a group owner may take note of available channels prior to establishing a group. For example, the device may note available and unavailable channels by considering beacons, probe requests, and group information advertisements from other devices in the environment.
In the timeline of
Pursuant to the 802.11™ standard, for nonmesh STAs, the Channel Switch Count field 425 may be set either to the number of target beacon transmission times (TBTTs) until the device sending the Channel Switch Announcement element switches to the new channel or is set to 0. Pursuant to the 802.11™ standard, a value of 1 may indicate that the switch occurs immediately before the next TBTT. A value of 0 may indicate that the switch occurs at any time after the frame containing the element is transmitted.
For mesh STAs, pursuant to the 802.11 standard, the Channel Switch Count field may be encoded as an octet with bits 6 to 0 set to the time, in units of 2 TU when the MSB (bit 7) is 0, or in units of 100 TU when the MSB (bit 7) is 1, until the mesh STA sending the Channel Switch Announcement element switches to the new channel. A value of 0 for bits 6 to 0 may indicate that the switch occurs at any time after the frame containing the element is transmitted.
A new field Transition Information field 425 consisting of N bytes, may be used to indicate whether the recipient is to form a new group on the designated channel, and if so, if it is to become the new group owner. For example, N may be 6 and the Transition Information field 425 may simply indicate a target MAC address. The recipient may infer form context how exactly the channel change is to be performed. In some embodiments, at least one device entering a new group will have AP capabilities such that it may serve as a group owner. However, in some embodiments it may suffice for the new group to comprise an IBSS without an explicit group owner. This information may be included in New Transition Information field 425 and may be used to more quickly join the new group owner and its clients. New Transition Information field 425 may also indicate which devices (e.g., which MAC addresses) are to accompany the device upon this transition. In some embodiments, new field 425 may indicate that the recipient, rather than the sender, is to transition to the New Channel Number 420 field.
As in the 802.11™ standard, the Channel Switch Announcement element 400 may be included in Channel Switch Announcement frames, in Beacon frames, in Probe Response frames, etc. However, rather than serving as a general broadcast message, the message may be directed to specific clients. Although the information for transitions is provided in new field 425 in this example, one will recognize that the information may appear elsewhere in the frame in some embodiments.
At block 510, the group owner may request that one or more client devices measure their channel quality. For example, the group owner may submit a MLME-MREQUEST message to each of the clients (e.g., as specified in the IEEE Standard 802.11-2012™). Requests may be sent not only to assess group owner-client communications, but also to assess client-to-client communications, e.g., across a DLS link. Clients that were previously asked to leave the group, that may now be Group Owners of their own groups, may also be queried to determine which channels they may have chosen to now operate upon. The group owner may use frame requests to ask that each client return RRM capabilities support status, link measurements to other clients, RCPI on supported channels, etc.
At blocks 515-525, the group owner may consider the results of the MLME-MREQUEST requests in conjunction with other factors to determine at block 530 whether a new configuration is desirable. For example, at block 515 the group owner may map channels to clients to assess channel occupancy. Such a mapping may include previous reassignments and notifications concerning reassignments from other Group Owners. At block 520, the group owner may consider, e.g., the RCPI levels returned from the link measurement requests for the group owner to client links. The RCPI, along with other characteristics of the channel may be considered, to determine whether a reassignment is desirable. At block 520, the group owner may map channel occupancy across the channels as well as group owner to client and client to client RCPI measurements. At block 525, the RCPI for client to client links may also be considered. Other factors, such as the number of frames received in an interval, retransmission rates, pass and failure rates, average access delays, etc., may also be considered.
At block 530, the group owner system may determine whether the collected data and channel information indicate that an improved channel configuration may be achieved by reallocating channels between devices in the current group. If one or more configurations have been identified, the system may select the most efficient reconfiguration and at block 540 begin issuing channel transition request messages. A record of the current client-channel map may be updated accordingly.
At block 535, the system may determine whether the collected data and channel information indicates that an improved channel configuration may be achieved by creating a new group operating on one or more new channels. If so, the group owner may issue channel transition request messages at block 545. These transitions may anticipate a subsequent group-ownership handoff to a client operating on the new channel(s) at block 550. The new group owner on the new channel(s) may then perform its own instance of the process 500, exchanging channel status information at block 510 with the original group owner. In this manner, the group owners may complement the information separately received via their own measurement requests. Passive scanning of the alternative channels may continue at block 555, e.g. by monitoring for frames in other channels to determine if neighboring devices have ceased their use of one or more channels.
As mentioned, numerous factors may be considered at blocks 530 and 535 when determining how to reorganize channel assignments. The group owner may group sets of clients into potential offloading targets based on, e.g.: clients with bandwidth-intensive persistent connections; the client's relative RCPI with the group owner; the client's relative RCPI to/from a desired peer; the client's mutual assessment of interference on a candidate offloading channel; the presence of legacy devices (e.g., 802.11b) in common connection that implement bandwidth-intensive connections; etc. The decision to transition clients to a new group at block 535 may be based on additional factors, e.g., the presence of a cellular data connection or the relative RCPI to most of the client peers.
One will recognize that
The memory 610 and storage devices 620 are computer-readable storage media that may store instructions that implement at least portions of the various embodiments. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, e.g., a signal on a communications link. Various communications links may be used, e.g., the Internet, a local area network, a wide area network, or a point-to-point dial-up connection. Thus, computer readable media can include computer-readable storage media (e.g., “non transitory” media) and computer-readable transmission media.
The instructions stored in memory 610 can be implemented as software and/or firmware to program the processor(s) 605 to carry out actions described above. In some embodiments, such software or firmware may be initially provided to the processing system 600 by downloading it from a remote system through the computing system 600 (e.g., via network adapter 630).
The various embodiments introduced herein can be implemented by, for example, programmable circuitry (e.g., one or more microprocessors) programmed with software and/or firmware, or entirely in special-purpose hardwired (non-programmable) circuitry, or in a combination of such forms. Special-purpose hardwired circuitry may be in the form of, for example, one or more ASICs, PLDs, FPGAs, etc.
The above description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the disclosure. However, in certain instances, well-known details are not described in order to avoid obscuring the description. Further, various modifications may be made without deviating from the scope of the embodiments. Accordingly, the embodiments are not limited except as by the appended claims.
Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
The terms used in this specification generally have their ordinary meanings in the art, within the context of the disclosure, and in the specific context where each term is used. Certain terms that are used to describe the disclosure are discussed below, or elsewhere in the specification, to provide additional guidance to the practitioner regarding the description of the disclosure. For convenience, certain terms may be highlighted, for example using italics and/or quotation marks. The use of highlighting has no influence on the scope and meaning of a term; the scope and meaning of a term is the same, in the same context, whether or not it is highlighted. It will be appreciated that the same thing can be said in more than one way. One will recognize that “memory” is one form of a “storage” and that the terms may on occasion be used interchangeably.
Consequently, alternative language and synonyms may be used for any one or more of the terms discussed herein, nor is any special significance to be placed upon whether or not a term is elaborated or discussed herein. Synonyms for certain terms are provided. A recital of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification including examples of any term discussed herein is illustrative only, and is not intended to further limit the scope and meaning of the disclosure or of any exemplified term. Likewise, the disclosure is not limited to various embodiments given in this specification.
Without intent to further limit the scope of the disclosure, examples of instruments, apparatus, methods and their related results according to the embodiments of the present disclosure are given above. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. In the case of conflict, the present document, including definitions will control.