Patent Application
20140192691
1. Technical Field
Embodiments of the present disclosure relate generally to wireless networks, and more specifically to techniques for reliable delivery of data specified for transmission by multicasting in wireless networks.
2. Related Art
A wireless local area network (WLAN) generally refers to a network in which devices communicate with each other over a wireless medium in conformity with IEEE 802.11 family of standards. As is well known, such technologies rely on an access point (AP), which normally operates as a switching device to facilitate wireless stations to communicate with each other, and also potentially with devices external to a WLAN. On the other hand, wireless stations typically are either source (where data is created/formed for transmission by wireless network) or destination (the eventual machine to which the packet is delivered) of data.
WLAN standards often specify certain types of data, which can be transmitted using multicast packets. As used in the present application, a multicast refers to WLAN multicast in that the destination address field specifies that the packet is destined for multiple machines. In particular, a destination MAC address field in a packet with the octets 01-00-5E-xx-xx-xx (i.e., the higher order 25 bits of the 48-bit destination MAC address) specifies that the packet is a multicast packet, with the specific multicast group being identified by the value of xx-xx-xx. A broadcast is a specific instance of a multicast in that all the machines in the WLAN are destination stations for the corresponding packets. Unicast in the description herein similarly refers to WLAN unicast, unless the context clearly indicates otherwise.
Unfortunately, the protocol mechanism may not be geared for reliable delivery of multicast packets. Aspects of the present invention provide for such reliable delivery of such data specified for transmission as multicast packets.
Example embodiments of the present invention will be described with reference to the accompanying drawings briefly described below.
The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
According to an aspect of the present invention, an access point (AP) of a WLAN maintains a list of wireless clients in the WLAN that belong to a special class. The AP receives a data packet to be transmitted to the wireless clients as a multicast packet, and examines the list to determine whether one or more of the wireless clients belongs to the special class. If none of the wireless clients belongs to the special class, the AP transmits the data as a multicast packet. However, if one or more wireless clients belong to the special class, the AP transmits the data in the form of unicast packets to each wireless client of the special class in addition to transmitting the data as a multicast packet. Such an approach may ensure reliable delivery of data specified for transmission by multicasting in wireless networks such as WLAN.
Several aspects of the invention are described below with reference to examples for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One skilled in the relevant arts, however, will readily recognize that the invention can be practiced without one or more of the specific details, or with other methods, etc. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the features of the invention.
System 100 is shown containing client devices (clients) 110A-110E, access point (AP) 110F, wired network 130, and wired network backbone 140. Block 110 represents a basic service set (BSS) consistent with the 802.11 standard. Other environments may include more than one BSS, with the BSSs being interconnected to form an extended service set (ESS) consistent with IEEE 802.11 standards.
AP 110F is connected by a wired medium (141) to wired network backbone 140 and thus to wired network 130. Each of clients 110A-110E may communicate with AP 110F (as well as with each other) wirelessly according to any of the family of IEEE 802.11 protocols (including as specified in IEEE 802.11a, 802.11b, 802.11g and 802.11n) and thereby with wired network 130. Wired network 130 may represent the internet, also known as the World Wide Web. One or more of clients 110A-110E may correspond, for example, to a laptop computer, smart phone, or a wireless sensor.
AP 110F may receive data destined for final delivery (and consumption) to one or more of clients 110A-110E. Such data may originate, for example, from a device in wired network 130, a wireless client in another WLAN BSS, or from any of clients 110A-110E (not including the client which is the destination). Based on the specific nature of the data, AP 110F may be required by corresponding standards (e.g., IEEE 802.11) to transmit (forward) the data encapsulated either as a unicast packet or as a multicast (or broadcast) packet.
In case of unicast packets, and in accordance with the IEEE 802.11 standard, AP 110F indicates, in a beacon frame, the specific ones of clients 110A-110E for which unicast packets are currently available in the AP for delivery. Each of the indicated clients thereafter sends a PS-poll frame indicating availability to receive the corresponding unicast packets directed to it (the indicated client(s)). Thus, unicast data are generally received reliably by the corresponding client.
On the other hand, in the case of at least some type of multicast packets, an AP merely notifies (without waiting to receive a PS-Poll or similar message frame) the expected time frame of future transmission of the multicast packets. In such scenarios, reliable receipt of the data (multicast data) transmitted in multicast packets cannot be ensured at least in some scenarios. The manner in which such a problem is overcome in embodiments of the present invention is illustrated next with respect to a flowchart.
In step 210, AP 110F maintains data indicating a list of clients (within network BSS 110) of a special class. A separate list may be maintained for each multicast address of interest. A special class implies that AP 110F needs to handle/process multicast data destined for the clients of the special class differently than for clients not of the special class. The determination of whether a client belongs to the special class may be made based on one or more considerations, examples of which are provided below. Furthermore, the list may be constantly updated, parallel to performance of the other steps of the loop described below. Control then passes to step 220.
In step 220, AP 110F receives data, which is specified (e.g., by protocol, application or addressing convention) to be transmitted to clients (two or more of clients 110A-110E) in the form of multicast packet(s). The data may be received from a wireless station within BSS 110 or external to BSS (e.g., from wire network 130 or clients of another BSS). Control then passes to step 240.
In step 240, AP 110F determines whether the special class (for that multicast address) has any members (i.e., non-empty list). AP 110F may make such determination based on examination of the list of step 210. If there are any such clients in the special class for that multicast address, control passes to step 260, and to step 270 otherwise.
In step 260, AP 110F transmits the data received in step 220 in the form of unicast packets to clients of the special class. In other words, the same data, though received in step 220 for transmission as broadcast data, is transmitted in the form of multiple unicast packets, with each packet destined to corresponding one of the clients of the special class. As noted above, in 802.11 family of protocols, reliable delivery is ensured by first notifying the clients of the availability of the packet, and the client thereafter sending a PS-poll frame to request delivery of the buffered packet. Control then passes to step 270.
In step 270, AP 110F transmits the data received in step 220 as multicast packets. Thus, the same data received in step 220, is transmitted in the form of unicast packets in step 260, and multicast packet in step 270. The clients in the special status list may need to be accordingly designed to ignore the duplicate reception. Control then passes to step 220, and the corresponding steps of the flowchart may be repeated in a corresponding loop.
It may be appreciated that the above approach ensures reliable delivery of multicast data to clients of the special class by transmitting the data as unicast packets. Transmission of multicast data to ‘conventional’ clients (i.e., clients not belonging to the special class) remains unchanged and occurs as per the IEEE 802.11 (WLAN) specifications.
An example situation in which such an approach may be useful is when clients of a WLAN network are allowed to operate in “sleep” modes to reduce power consumption. For example, in the context of IEEE 802.11 operation, a client (e.g., 110A) may operate in the standard Power Save Poll Mode (PSPM, or power-save mode, in general), as described in section 10.2.1.2 of the IEEE 802.11[TM]-2012 specification. Upon joining BSS 110, client 110A communicates to AP 110F that it (client 110A) is to operate in PSPM.
In PSPM, client 110A periodically “wakes up” (i.e., powers-ON for full functionality) from a power-OFF or reduced power state to transmit data to, or receive data from, AP 110F or the other clients of BSS 110, as illustrated in
At least in some situations, it may be desirable to operate client 110A in sleep mode as often and as long as possible. An example is when client 110A is a temperature sensor that typically needs to update temperature measurements only once every few minutes (by comparison beacons from AP 110F are typically transmitted every 100 ms (milliseconds)). In
The sequence of operations that occur in transmission of unicast data according to IEEE 802.11 from AP 110F to client 110A is illustrated in
It is noted that at the time of association with AP 110F, client 110A may indicate to AP 110F a sleep interval (e.g., the time duration equal to six beacons in
AP 110F is made aware, for example based on interactions with client 110A and client 110B (as noted in sections below), that clients 110A and 110B are to be treated as belonging to a special class with respect to transmission of multicast data. For example, client 110A informs, during association with AP 110F, such a requirement. Client 110A may indicate to AP 110F a requirement to be treated as belonging to the special class in vendor specific information elements (IE) of a probe request message. AP 110F may indicate support for such sleepy devices (for transmitting broadcast/multicast packets as unicast packets) as part of vendor-specific IE (information elements) of a probe response message. Alternatively, AP 110F may broadcast beacons indicating support for clients of the special class, and client 110A may thereafter request AP 110F for such support.
While the determination of whether a client is to be treated as belonging to a special class is noted above as being made based on whether or not the client is to operate as a sleepy device, the determination may be made on other considerations as well.
For illustration, it is now assumed that an ARP (Address Resolution Protocol) request is received by AP 110F, for forwarding to each of the clients in BSS 110. For example, if a device in a same IP (Internet Protocol) subnet as clients 110A-110E needs to send data to one (say client 110A) of clients 110A-110B, but does not have the MAC address of client 110A (i.e., does not have a corresponding ARP entry), the device may send an ARP request to AP 110F for eventual delivery to clients 110A-110E.
Given that there are two devices 110A/110B, which have previously registered with the special status, AP 110F forms a unicast packet containing the ARP request. As shown in
Similarly, as shown in
With reference to
Since clients 110C, 110D and 110E do not belong to the special class, AP 110F transmits the ARP request as ‘regular’ multicast packet, as illustrated in
Another benefit of the approach of the flowchart of
Typically, the duration of buffering (within AP 110F) of a new group key is short to ensure greater (or faster enforcement of) security in the WLAN. Thus, for example, it may not be a practical solution to have AP 110F buffer the new group key, as well as to delay transmission of the next multicast packet, for too long a duration. Further, non-acknowledgement of a group key update may potentially result in client 110A being dissociated from the WLAN. With the technique of
AP 110F can be implemented in various embodiments as a desired combination of one or more of hardware, executable modules, and firmware. The description is continued with respect to an example embodiment in which various features are operative when corresponding instructions are executed by a processor.
Again, the components/blocks of
Wireline network interface provides AP 110F connection to wired backbone 140 via path 141 (
Antenna 695 operates to receive from and transmit to a wireless medium, corresponding wireless signals (e.g., according to IEEE 802.11) containing data. Switch 690 may be controlled by processing block 610 (connection not shown) to connect antenna 695 either to receive block 680 via path 698, or to transmit block 670 via path 679, depending on whether AP 110F is to receive or transmit.
Transmit block 670 receives data to be transmitted on path 671 from processing block 610, generates a modulated radio frequency (RF) signal according to IEEE 802.11 standards, and transmits the RF signal via switch 690 and antenna 695. Receive block 680 receives an RF signal bearing data via switch 690 and antenna 695, demodulates the RF signal, and provides the extracted data to processing block 610 on path 681.
RTC 640 operates as a clock, and provides the ‘current’ time to processing block 610 on path 641. RTC 640 may be backed-up by battery 645 (in addition to the normal source of power, not shown in the Figure). RTC 640 may also contain memory to store critical information received from processing block 610. Although not shown as such in
Non-volatile memory 650 is a non-transitory machine readable medium, and stores instructions, which when executed by processing block 610, causes AP 110F to provide several desired features according to the present invention. RAM 630 and non-volatile memory 650 (which may be implemented in the form of read-only memory/ROM/Flash/EEPROM, etc.) constitute computer program products or machine (or computer) readable medium, which are means for providing instructions to processing block 610. Thus, such medium can be in the form of removable (floppy, CDs, tape, etc.) or non-removable (hard drive, etc.) medium.
Processing block 610 (or processor in general) may contain multiple processing units internally, with each processing unit potentially being designed for a specific task. Alternatively, processing block 610 may contain only a single general-purpose processing unit. Processing block 610 may retrieve the instructions (via corresponding paths 651 and 631), and execute the instructions to provide several features of the present invention described above.
In particular, processing block 610 may interface with the clients to determine the members of special status. A separate list may be maintained for each broadcast/multicast address since only some of the clients may be members of some of the multicast groups. Accordingly, each client may be required to indicate the specific multicast addresses for which the client is to be treated with special status. A client of special status for any multicast address is treated as similar status for broadcast address. The lists thus formed, may be stored in RAM 620. Alternatively, only a single list for all the multicast addresses together, may be maintained. Processing block 610, when processing data specified for transmission/forwarding as multicast packets, examines the corresponding list in RAM 620, in determining the specific clients to which the data to be forwarded in the form of unicast packets as in step 260.
References throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present invention should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.
