Patent Application
20150381377
The present invention relates to wireless communications, and more particularly to methods and apparatuses for managing multicast addresses and connectivity arrangements for transporting multicast data in a wireless network.
As WiFi networks become nearly ubiquitous, new applications for WiFi are continually being developed. For example, the original IEEE 802.11 standards did not include any support for multicast or groupcast transmissions in the wireless network (i.e. a basic service set, or BSS), which would be useful for applications such as audio and video distribution. Similarly, new technologies have been emerged such as WiFi Direct.
Recently, however, the IEEE 802.11aa standard included definitions for multicast/groupcast transmissions, including a mechanism where a WiFi access point (AP) can provide reliability by allowing for retransmissions of multicast/groupcast (MG) data. The retransmitted MG data is transmitted with a different multicast/groupcast address than the original transmission. This is to ensure that “legacy devices” (i.e., devices that don't support the newer 802.11aa standards) in the network will not be receiving the retransmitted packets, as legacy devices cannot do duplicate packet detection of MG data. An AP can allocate the retransmission address locally as it can safely assume that it is the only device in the network (i.e. BSS) that is allowed to transmit MG data. However, there is currently no standard or other mechanism to enable the use of reliable MG data transmission by non-AP STAs in the BSS and also by devices in WiFi Direct networks (both group owners and clients).
The present invention provides methods and apparatuses for managing multicast addresses and connectivity arrangements for transporting multicast data in a wireless network. According to certain aspects, embodiments of the invention enable allocation of multicast addresses to facilitate reliable multicast/groupcast transmissions by any device in a wireless network, and not just an access point, as well as in wireless networks where there is no support for 802.11aa. According to certain other aspects, embodiments of the invention allow for multicast transmission to sinks in a wireless network that are not reachable to the source device, even when the source device is in a BSS or other environment comprising an access point that does not support IEEE 802.11aa.
According to these and other aspects, a method for managing multicast/groupcast (MG) data communications in a wireless system comprising an access point (AP) device, a source device that is separate from the AP device and one or more sink devices that are separate from both the AP and source devices according to embodiments of the invention includes allocating a multicast address by the source device; and wirelessly transmitting MG data from the source device to the one or more sink devices using the allocated multicast address.
These and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein:
The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.
According to certain general aspects, embodiments of the invention provide methods for allocating a multicast address for multicast data transmission by a non-AP source device.
IEEE 802.11aa protocol allocates the Layer 2 (i.e. MAC) address for multicast data transmissions based on IETF RFC 3376, in which the IP address of the multicast stream is used to formulate the MAC address (i.e. add a prefix to the IP address), while the re-transmission address is allocated locally by the AP (i.e. one unique address can be allocated for each stream or one address can be the same for all the streams). However, the present inventors recognize that it may be desirable for devices other than the AP to perform multicast data transmissions, in which case a different scheme for allocating multicast addresses is needed.
Although embodiments of the invention will be described in connection with WiFi networks in compliance with IEEE 802.11 standards, the invention is not limited to this example. For example, the principles of the invention can be extended to other wireless communication systems and devices such as WiFi Direct, Adhoc WiFi (IBSS), etc. Those skilled in the art will appreciate how to implement the invention in these and other systems and devices after being taught by the present examples.
A block diagram of an example alternative WiFi BSS 100 according to embodiments of the invention is shown in
Specifically,
Source device 102 is an audio/video device capable of rendering content (e.g. MPEG video, MP3 audio, etc.) and also having capabilities of acting as a multicast master. As such, source device 102 has built-in WiFi functionality (e.g. a WiFi chipset and associated firmware/software) that preferably supports IEEE 802.11aa, as well as the additional functionalities of the present invention as will be described below. Those skilled in the art will be able to understand how to implement the present invention by adapting IEEE 802.11 functionality of such chipsets and associated firmware/software after being taught by the present examples.
Sink devices 106 are audio/video devices capable of rendering content (e.g. a WiFi speaker that can playback audio from MPEG video, MP3 audio, etc.) and also having capabilities of acting as a multicast slave. As such, sink devices 106 have built-in WiFi functionality (e.g. WiFi chipsets and associated firmware/software) that preferably support IEEE 802.11aa, as well as the additional functionalities of the present invention as will be described below. Those skilled in the art will be able to understand how to implement the present invention by adapting IEEE 802.11 functionality of such chipsets and associated firmware/software after being taught by the present examples.
AP 104 can be implemented by, for example, a wireless access point or router that supports IEEE 802.11aa. However, the invention is not limited to this example and can include any type of wireless station including access points and routers, as well as devices that do not support IEEE 802.11aa.
In a typical operation of the WiFi audio system included in BSS 100, a user selects content for playback using DMC 110, which sends control commands to DMS 108 via AP 104 using TCP/IP over WiFi. In response, DMS 108 sends the selected content to source device 102 via AP 104. Source device 102 then transmits the data via multicast to sink devices 106 using UDP/IP over WiFi and MSDU frames as defined by IEEE 802.11a, and as possibly modified by embodiments of the invention. The selected content is then rendered by sink devices 106.
Because non-AP source device 102 is transmitting multicast data to sink devices 106 in BSS 100 rather than, or in addition to, AP 104, it is required to allocate the Layer 2 multicast address. This is primarily because the content that is transmitted by source device 102 is a multicast IP stream. However, allocating the MAC address for the multicast stream locally by device 102 would require ensuring that the multicast address used is not used elsewhere in the network. This is the same problem that one would face in allocating the retransmission MAC address to realize the 802.11aa protocol. However, in that case, given that an AP based solution is more centralized (i.e. addresses used can be controlled by the administrator of the network via the AP), the probability of an overlap of retransmission MAC address with another device in the network using the same address is minimal.
In the example embodiment of the invention of
In situations where device 102 is the device in BSS 100 that is primarily transmitting multicast data, it can use the MAC address of the multicast stream as allocated above for re-transmissions as well. This is for cases where there are no legacy IEEE 802.11 devices in the BSS 100 that are receiving multicast data from device 102. If there are legacy devices in the BSS, the MAC address for the multicast stream can be the same as the MAC address that is allocated as defined in IEEE 802.11aa, but the retransmission MAC address for the multicast stream is allocated as described above.
As shown in
Embodiments of the invention such as that shown in
It should be noted that various acknowledgment mechanisms can also be employed in embodiments of the invention, including those defined by IEEE 802.11aa, as well as those described in co-pending application No. ______ (CONTX13061).
Therefore, according to certain other aspects alluded to above, embodiments of the invention provide connectivity options to transport multicast data that uses the allocated multicast address to allow for retransmission of multicast data.
Transporting multicast data using the connectivity embodiment shown in
The example embodiment of BSS 300 in
In one example, this signaling could be performed by the sink device signaling to source that it is able to receive the multicast data that is being sent by the source by the received acknowledgments from the sink device. In another example, the signaling could include the source signaling to the sink that it is switching the stream from multicast to unicast or vice versa, along with an associated response back from the sink device. These messages can be defined as part of encapsulated data frames and that would allow the transport of the messages even without the support of the AP.
The connectivity example shown in
In the connectivity example of BSS 400 shown in
However, if the AP 404 does not support IEEE 802.11aa, it is not possible to transport the multicast data reliably because there is no support for retransmissions as in IEEE 802.11aa. To facilitate reliability in this scenario, the following method can be used to allow for reliability.
First, a bit map is established at the source device 402 to maintain the reception status of data for sink devices 408 that are receiving multicast data via the AP 404. The source device 402 includes the Sequence Number (Seq. No.) of the data that is transmitted in the data portion that is transmitted to the AP 404. The AP 404 adds its own Seq. No to the data (i.e. the data already includes the Seq. No. from source device 402) that is transmitted to the sinks 408 via a multicast stream. The encoding of the Seq. No. by the source device 402 of the data that is being transmitted to the AP404 can be in an “A-MSDU header” (e.g. the Seq No. for the 802.11 MAC frame is a 12 bits field) or in the actual data itself. Additionally, since the purpose of tracking the sequence number of the packet is to correlate the frame transmitted by the source to the AP, which is then transmitted as a multicast frame by the AP to sink devices, the Seq. No. can be a simple encoding that can fit into the existing MAC header (e.g. a few bits instead of 12 bits for MAC Seq. No.), of an A-MSDU header.
Even though the multicast data is transmitted via AP 404 (with its own Seq. No. allocated by AP 404), it is possible for the source device 402 to track the reception of the packets at the sink devices 408 as follows. The multicast data will be transmitted by the AP 404 typically at beacon time and it will allocate its own Seq. No. for the data that it transmits. The multicast data transmitted by the AP 404 is also received by the source device 402 as the multicast address used by the AP404 to transmit the data is known to the source device. Upon receiving the multicast data transmitted by the AP 404, the source device 402 can correlate the original Seq. No. of the same data (e.g. encoding in MAC header, or A-MSDU header or limiting number of packets transmitted from source to AP to no more than one frame at a time) that it transmitted to the AP 404 to the Seq. No. used by the AP 404 to transmit the same data.
The source device 402 transmits a unicast message to each sink device 408 that is receiving multicast data from the AP 404 with the following information: (1) the original Seq. No. of the data as transmitted by the source device 402; (2) the Seq. No. of the same data that is transmitted by the AP 404; and (3) a request for acknowledgement.
The sinks 408 receive the unicast message from the source device 402 (via AP 404) and transmit a response that includes a bit map of the data as follows: (1) the starting Seq. No. (from the source device 402); and (2) a bit map signaling the reception of each MSDU after the Seq. No. Because the sinks 408 that are receiving the data from the AP 404 know the original Seq. No. from the source of the data that they are receiving from the AP 404, they can do duplicate detection. In this case, the overhead is N_sink*acknowledgement.
The amount of overheads (i.e. additional signaling and medium time required to allow for data reception by sink devices from the AP) in this example are as follows. The size of the frame=MAC Headers+Number of Data Frames*(12 bits original Seq. No.+12 bits Seq. No. of the same data transmitted by the AP 404)=MAC Headers+3 bytes*N (where N is the number of multicast data frames transmitted by the AP 404 after which an acknowledgement is requested). The number of channel accesses=2 (Source device 402 to AP 404 and then AP 404 to sink devices 408). Therefore, if the number of sinks 408 receiving content from AP 404 is N_sink then the total amount of overheads=N_sink*2*(MAC Header+3 bytes*N+channel accesses).
Note that in the connectivity example shown in
An alternative to the above connectivity example is shown in
Although the present invention has been particularly described with reference to the preferred embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details may be made without departing from the spirit and scope of the invention. It is intended that the appended claims encompass such changes and modifications.
