WO2008020731A1

WO2008020731A1 - Multicast procedure in a wireless network

Info

Publication number: WO2008020731A1
Application number: PCT/KR2007/003946
Authority: WO
Inventors: Ji Young Huh; Jin Ho Son; Sook Hyun Yang; Vladimir M. Vishnevsky; Andrey I. Lyakhov; Mikhail Y. Yakimov; Alexander A. Safonov
Original assignee: Lg Electronics Inc.
Priority date: 2006-08-17
Filing date: 2007-08-17
Publication date: 2008-02-21

Abstract

Provided is a method of providing a multicast service in a wireless network in a further effective and reliable manner. The multicast method including: transmitting, by a first station, a plurality of data frames in which a destination address field is set to an address of a specific multicast group; and performing a block acknowledgment (ACK) procedure between one or more second stations registered to the multicast group and the first station. The step of performing a block ACK procedure includes: transmitting, by the first station, a block ACK request frame to the second station; and transmitting, by the second station, a block ACK response frame which indicates whether the plurality of data frames are successfully received in response to the block ACK request frame. The block ACK procedure is performed by unicast, and wherein the block ACK procedure is performed with respect to all stations registered to the multicast group or is performed with respect to only one or more stations.

Description

MULTICAST PROCEDURE IN WIRELESS NETWORK

Technical Field

[1] The present invention relates to wireless communication, and more particularly, to a multicast procedure in a wireless network. Background Art

[2] In wireless communication, message transmission types may be classified into unicast, multicast, and broadcast according to the number of target devices or destination devices. Unicast is a message transmission type in which a destination device for transmitting a message consists of one terminal. Both multicast and broadcast are a message transmission type in which the destination device for transmitting the message consists of a plurality of terminals. In multicast, a target address or a destination address field of a transmission frame is set as a multicast group address. Broadcast is special multicast in which the multicast group address identifies all terminals. Therefore, hereinafter, the term 'multicast' is intended to include the term 'broadcast', unless not permitted by nature.

[3] In wireless communication, in order for one source terminal to transmit the same data to a plurality of destination terminals, copies of individual pieces of data are respectively transmitted to the destination terminals. By doing so, reliability of data transmission can be ensured. However, there is a demerit in that the source terminal has to repeat the same transmission procedure by the same number of times as the number of the destination terminals, resulting in the increase in wireless traffic. That is, when unicast is repeated by the same number of times as the number of the destination terminals, a lot of channel resources are consumed, which is not effective even for an application with low traffic.

[4] On the other hand, in multicast, a single data stream is simultaneously transmitted to a plurality of destination terminals, and thus data traffic can be reduced, and a channel can be effectively used. Such multicast may be useful in the provision of various applications, for example, video conference, corporate communication, distance learning, software distribution, stock quotes, news, and so on. Furthermore, multicast can be used in a game which is played by multi-users over a wireless home network or be used in an application that shares streaming data.

[5] The multicast is based on a concept of a recipient terminal group (i.e., multicast group) interested in a specific data stream. In order to receive multicast data, terminals interested in the reception of the multicast data have to be registered to a multicast group. In a Medium Access Control (MAC) layer, the multicast group is identified by a multicast MAC address. In general, a higher layer than the MAC layer is responsible for generation, registration, deregistration, and modification of the multicast group. Since such issues (e.g., generation, registration, etc.) of the multicast group are identified by the MAC address, descriptions thereof will not be discussed herein.

[6] When a multicast service is provided, it is difficult to check whether a terminal registered to a multicast group, that is, a destination terminal, successfully receives data provided from a source terminal. In particular, the Institute of Electrical and Electronic Engineers (IEEE) 802.11 standard does not define an error recovery mechanism for multicast traffic. In addition, a method of preventing collision between a multicast frame and another frame is not defined in the IEEE 802.11 standard. Therefore, a currently available multicast service does not guarantee that a destination terminal can receive multicast data in a complete and reliable manner. Since multicast data suffers from a high probability of data loss due to interference, collision, or a time- varying channel feature, multicast traffic has reliability lower than that of unicast traffic. Accordingly, there is a need for a method for providing a multicast service in a further reliable and effective manner. Disclosure of Invention Technical Problem

[7] The present invention provides a multicast procedure in which a multicast service can be provided through a wireless network in a further reliable and effective manner. Technical Solution

[8] According to an embodiment of the present invention, there is provided a multicast method in a wireless network, comprising the steps of: transmitting, by a first station, a plurality of data frames in which a destination address field is set to an address of a specific multicast group; and performing a block acknowledgment (ACK) procedure between one or more second stations registered to the multicast group and the first station.

[9] According to an aspect of the aforementioned embodiment, the step of performing a block ACK procedure may comprise: transmitting, by the first station, a block ACK request frame to the second station; and transmitting, by the second station, a block ACK response frame which indicates whether the plurality of data frames are successfully received in response to the block ACK request frame. In this case, the block ACK procedure may be performed by unicast, and the block ACK procedure may be performed with respect to all stations registered to the multicast group or is performed with respect to only one or more stations.

[10] According to another aspect of the aforementioned embodiment, the multicast method may further comprise, prior to the step of transmitting a plurality of data frames, ensuring a channel between one or more third stations registered to the multicast group and the first station. In this case, the ensuring of a channel may comprise exchanging a Request To Send (RTS) frame and a Clear To Send (CTS) between the first station and the third station. In addition, members of the multicast group may do not have neighboring stations hidden from the first station, and the third station may be any one of stations selected from the members of the multicast group. In addition, the members of the multicast group may have one or more fourth stations having neighboring stations hidden from the first station, and the third station may include all of the fourth stations.

[11] According to another embodiment of the present invention, there is provided a multicast method in a wireless network, comprising the steps of: transmitting, by a first station, a first multicast block ACK setup request frame in which a destination address field is set to an address of a specific multicast group; and transmitting, by a second station which belongs to members of the multicast group and intends to use a block ACK mechanism in a multicast service, a multicast block ACK response frame to the first station in response to the first multicast block ACK setup request frame.

[12] According to an aspect of the aforementioned embodiment, the multicast method may further comprise: transmitting, by the first station, a plurality of data frames in which a destination address field is set to an address of a multicast block ACK group including the second station; and transmitting, by the second station, a block ACK frame after the plurality of data frames are all received.

[13] According to another aspect of the aforementioned embodiment, the multicast block ACK response frame may include information on a maximal buffer size that can be used by the second station and may further comprise: determining a maximal burst size of data that is multicast in a subsequent step by using information on the maximal buffer size by the first station receiving the multicast block ACK response frame; and transmitting, by the first station, a second multicast block ACK setup request frame which includes the maximal burst size and in which a destination address field is set to an address of a specific multicast group. In this case, the multicast procedure may further comprise: multicasting, by the first station, a data frame having a data size less than or equal to the maximal burst size; and transmitting, by the second station, a block ACK frame to the first station.

[14] According to another embodiment of the present invention, there is provided a multicast method in a wireless network, comprising: selecting one or more recipient stations from members of a multicast group by an originator station that intends to transmit multicast data; performing a channel ensuring procedure by using unicast traffic between the originator station and the selected recipient station; transmitting, by the originator station, the multicast data in which a destination address field is set to an address of the multicast group; and performing a block ACK procedure on the transmitted multicast data between the originator station and the selected recipient station.

[15] According to an aspect of the aforementioned embodiment, all of the members of the multicast group may do not have neighboring stations hidden from the originator station, and the selected recipient station may be any one of stations belonging to the members of the multicast group.

[16] According to another aspect of the aforementioned embodiment, one or more stations selected from the members of the multicast group may have neighboring stations hidden from the originator station, and the selected recipient station may include the one or more stations.

Advantageous Effects

[17] According to the present invention, a multicast service can be provided through a wireless network in a further effective and reliable manner. Brief Description of the Drawings

[18] The above and other features and advantages of the present invention will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings in which:

[19] Fig. 1 illustrates an example of a conventional management frame format;

[20] Fig. 2 illustrates a frame control field of Fig. 1 ;

[21] Fig. 3 is a message flow diagram illustrating a procedure for generating a multicast block ACK group and for transmitting multicast data by using the generated multicast block ACK group according to an embodiment of the present invention; [22] Fig. 4 is a message flow diagram illustrating an RTS-I procedure according to an embodiment of the present invention; [23] Fig. 5 is a message flow diagram illustrating a Block ACK (B-ACK) procedure according to an embodiment of the present invention; [24] Fig. 6 is a view for explaining a multicast transmission procedure according to an embodiment of the present invention, when there is no recipient having a neighboring station hidden from an originator; [25] Fig. 7 is a message flow diagram illustrating an indirect multicast procedure according to an embodiment of the present invention; [26] Fig. 8 is a message flow diagram illustrating an indirect multicast procedure modified according to another embodiment of the present invention; [27] Fig. 9 is a view for explaining an RTS-CTS exchange procedure, a multicast data transmission procedure, and an ACK procedure, each of which is performed for reliable multicast data transmission when there is a recipient having a neighboring station hidden from an originator;.

[28] Fig. 10 illustrates a simulation scenario in a hot spot;

[29] Fig. 11 illustrates a simulation scenario in a narrow ring;

[30] Fig. 12 and Fig. 13 are graphs showing simulation results related to a throughput with respect to an average transmission time in a hot spot scenario;

[31] Fig. 14 and Fig. 15 are graphs showing simulation results related to an average percent of packet losses and a maximal percent of packet losses in a hot spot scenario;

[32] Fig. 16 and Fig. 17 show simulation results related to a throughput and an average transmission time in a ring scenario; and

[33] Fig. 18 and Fig. 19 show simulation results related to an average percent of packet losses and a maximal percent of packet losses in a ring scenario. Best Mode for Carrying Out the Invention

[34] Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. The exemplary embodiments should be considered in descriptive sense only and not for purposes of limitation.

[35] In the present invention, in order to provide a reliable multicast service, a terminal that has received a multicast frame transmits to an originator of the multicast frame an acknowledgement (ACK) frame for the received multicast frame. In particular, ACK is collectively carried out for a plurality of multicast frames rather than individually carried out for each multicast frame received. A method for collective ACK may use a block ACK scheme. The collective ACK may not only increase reliability in the transmission of a multicast frame but also decrease overhead that occurs when a plurality of ACK frames are transmitted.

[36] According to one aspect of the present invention, a data burst size for collectively transmitting ACK messages (i.e., a size of a multicast data stream received prior to the transmission of a block ACK frame) is informed to a destination terminal in advance. In addition, the data size is determined according to a size of buffer included in the destination terminal. This will be described in detail hereinafter.

[37] In the provision of a multicast service, in order to use a collective ACK mechanism according to an embodiment of the present invention, it is necessary to setup a collective ACK in advance between an originator and a recipient of a multicast data packet. In the collective ACK, an ACK frame is transmitted only one time for a plurality of received frames. For example, the collective ACK may use a block ACK method. The block ACK method of the multicast service may be determined in such a way that the originator transmits to the recipient a multicast block ACK setup request (e.g., Multicast (Mcst) ADD Block ACK (ADDBA) request) message, and the recipient transmits to the originator a multicast block ACK setup response (e.g., Mcst ADDBA response) message in response to the multicast block ACK setup request message.

[38] Now, a multicast block ACK setup request/response message format will be described. The Mcst ADDBA request/response frame will be described hereinafter as an example. However, the present invention is not limited thereto.

[39] Fig. 1 is a block diagram illustrating an example of a format of a Mcst ADDBA request frame or a Mcst ADDBA response frame (e.g., conventional ADDBA request frame or ADDBA response frame) which can be used in the process of determining a block ACK scheme. Referring to Fig. 1, the conventional ADDBA request/response frame includes a frame control field, a duration field, a Destination Address (DA) field, a Source Address (SA) field, a Basic Service Set Identifier (BSSID) field, a sequence control field, a frame body field, and a Frame Check Sequence (FCS) field. The frame format of Fig. 1 is the same as the conventional management frame format used in a wireless network, and thus detailed descriptions thereof will be omitted.

[40] Fig. 2 illustrates the frame control field of the ADDBA request/response frame of

Fig. 1. Referring to Fig. 2, the frame control field includes a protocol version subfield, a type subfield, a subtype subfield, a 'To DS' subfield, a 'From DS' subfield, a 'More Fragment' subfield, a 'Retry' subfield, a 'Pwr MgL' subfield, a 'More Data' subfield, a 'WEP' or 'Protected Data' subfield, and an 'Order' subfield. Among the aforementioned subfields, the type subfield and the subtype subfield are provided to indicate frame functions. More specifically, according to information inserted into the type subfield, it is possible to recognize to which frame the frame of Fig. 1 is associated among three frames (i.e., control frame, data frame, and management frame). In addition, each frame type includes a plurality of defined subtypes. Table 1 shows an example of valid combinations of information elements that can be contained in the type subfield and the subtype subfield. The ADDBA request/response frame has a type subfield indicating a management frame and a subtype subfield indicating an action frame. Thus, the type subfield and the subtype subfield may respectively contain '01' and 1I lOl¹.

[41] Table 1

[42] The frame body field of the ADDBA request frame may include information elements shown in Table 2 below. [43] Table 2

[44] Referring to Table 2, the frame body field of the ADDBA request frame includes a category subfield, an action subfield, a dialog token subfield, a block ACK parameter set subfield, a block ACK timeout value subfield, and a block ACK starting sequence control subfield. In the case of the ADDBA request frame, the category subfield is set to a value (e.g., '3') indicating a block ACK, and the action subfield is set to a value (e.g., '0') indicating an ADDBA request frame.

[45] Furthermore, the frame body field of the ADDBA response frame may include information elements shown in Table 3 below. [46] Table 3

[47] Referring to Table 3, the frame body field of the ADDBA response frame includes a category subfield, an action subfield, a dialog token subfield, a status code subfield, a block ACK parameter set subfield, and a block ACK timeout value subfield. In the case of the ADDBA response frame, the category subfield is set to a value (e.g., '3') indicating a block ACK, and the action subfield is set to a value (e.g., T) indicating an ADDBA response frame.

[48] The Mcst ADDBA request/response frame used in a setup procedure included in a multicast block ACK process according to an embodiment of the present invention has a format similar to the ADDBA request/response frame used in a setup procedure included the aforementioned block ACK procedure by unicast. However, in the Mcst ADDBA request/response frame, a recipient address is allowed to be set to a multicast address. Furthermore, the Mcst ADDBA request/response frame may further include an additional unit (e.g., buffer size subfield and/or setup subfield) which is not included in the conventional ADDBA request/response frame. The Mcst ADDBA request/response frame is a new action frame which is different from the conventional ADDBA request/response frame. The ADDBA request/response frame may be used to setup and manage a multicast block ACK procedure, more particularly, to generate a multicast group for a multicast block ACK service, to manage the group, to be registered to the group, and to be deregistered from the group.

[49] In an example of the format of the Mcst ADDBA request/response frame according to one aspect of the present embodiment, action frame fields of the ADDBA request/ response frame described with reference to Fig. 1, Fig. 2, and Tables 1 to 3 are used without alteration. In this case, a specific multicast address is used for a recipient address field of the Mcst ADDBA request/response frame. In addition, the category subfield and/or the action subfield of Tables 2 and 3 may be set to reserved values indicating the Mcst ADDBA request frame and the Mcst ADDBA response frame.

[50] In another example of the format of the Mcst ADDBA request/response frame according to one aspect of the present embodiment, in addition to the use of a multicast address as a recipient address, a subfield for new information is added to the ADDBA request/response frame for setting a block ACK by unicast. The new information may contain a buffer size subfield for determining a data burst size and/or a setup subfield.

[51] For example, the frame body field of the Mcst ADDBA request frame, which is newly defined according to one aspect of the present embodiment, may include information elements shown in Table 4.

[52] Table 4

[53] Referring to Table 4, the frame body field of the Mcst ADDBA request frame includes a category subfield, an action subfield, a dialog token subfield, a multicast block ACK parameter set subfield, a multicast block ACK timeout value subfield, and a multicast block ACK starting sequence control subfield. The category subfield may be set to a value (e.g., '4') indicating a multicast block ACK, and the action subfield may be set to a value (e.g., '0') indicating a Mcst ADDBA request frame.

[54] Likewise, the frame body field of the Mcst ADDBA response frame, which is newly defined according to one aspect of the present embodiment, may include information elements shown in Table 5.

[55] Table 5

[56] Referring to Table 5, the frame body field of the Mcst ADDBA response frame includes a category subfield, an action subfield, a dialog token subfield, a status code subfield, a multicast block ACK parameter set subfield, and a multicast block ACK timeout value subfield. The category subfield may be set to a value (e.g., '4') indicating a multicast block ACK, and the action subfield may be set to a value (e.g., T) indicating a Mcst ADDBA response frame.

[57] A management frame for ending a block ACK determined by multicast according to one aspect of the present embodiment, that is, a frame body field of a Mcst Delete Block ACK (DELBA) frame, may include information elements shown in Table 6.

[58] Table 6

[59] Referring to Table 6, the frame body field of the Mcst DELBA frame includes a category subfield, an action subfield, a multicast DELBA parameter set subfield, and a reason code subfield. The category subfield may be set to a value (e.g., '4') indicating a multicast block ACK, and the action subfield may be set to a value (e.g., '2')indicating a Mcst DELBA frame.

[60] Now, a procedure for managing a group (e.g., multicast block ACK group) that uses a multicast block ACK service according to an embodiment of the present invention will be described. As described above, a multicast address for the multicast service is assumed to be selected in a higher layer than a Medium Access Control (MAC) layer. The multicast address is reported for a multicast originator and a potential recipient. It will be assumed that the multicast block ACK service according to the present embodiment is provided to stations registered to the multicast group.

[61] According to the present embodiment, an originator transmitting multicast data determines a new group (e.g., multicast block ACK group) for multicast block ACK prior to the transmission of the multicast data. The multicast block ACK group includes stations which intend to use a multicast block ACK service according to the present embodiment and may be formed by exchanging a multicast block ACK setup request frame and a multicast block ACK setup response frame. According to one aspect of the present embodiment, a setup procedure of the multicast block ACK group may include a process for matching a maximal data burst size with respect to all group members belonging to the multicast block ACK group. Although an originator does not belong to the multicast group in general, the originator may be a station that belongs to the multicast group.

[62] Fig. 3 is a message flow diagram illustrating a procedure for generating a multicast block ACK group and for transmitting multicast data by using the generated multicast block ACK group according to an embodiment of the present invention.

[63] Referring to Fig. 3, in order to setup a multicast block ACK group, an originator transmits a multicast block ACK setup request frame (i.e., Mcst ADDBA request frame) to recipients more than two times (step S31). The originator may be either a non-AP station (STA) or an Access Point (AP), where the STA is an arbitrary function medium including an MAC layer in compliance with an IEEE 802.11 standard and a physical layer interface for a wireless medium. Such STA may also be referred to as a radio station, a Wireless Transmit/Receive Unit (WTRU), a User Equipment (UE) unit, a Mobile Station (MS), a mobile subscriber unit, and so on. The AP may also be referred to as a central controller, a Base Station (BS), a node-B, a site controller, and so on. The recipients are STAs registered to the multicast group.

[64] The Mcst ADDBA request frame may be transmitted two times or more (e.g., mM- cstlnitNumber times). The reason of transmitting the Mcst ADDBA request frame several times is to ensure reception for all recipients. That is, if the originator transmits the Mcst ADDBA request frame only one time, it is not ensured that all recipients can properly receive the Mcst ADDBA request frame transmitted from the originator. Furthermore, a probability of receiving the Mcst ADDBA request frame transmitted from all recipients increases in proportion to the number of times of transmission. The number of times of transmission of the Mcst ADDBA request frame has to be determined in consideration of channel usage efficiency. The originator operates a timer after a last Mcst ADDBA request frame is transmitted. An expiration time of the timer is appropriately set. For example, the expiration time of the timer may be mMcs- tlnitTimeout.

[65] In response to the Mcst ADDBA request frame, each recipient transmits a multicast block ACK setup response frame (e.g., Mcst ADDBA response frame) (step S32). Each recipient may be a non-AP STA. The Mcst ADDBA response frame is transmitted within the aforementioned expiration time of the timer (e.g., mMcs- tlnitTimeout). In this case, if an Immediate Block ACK (Imm-ACK) policy is applied between the originator and a recipient, STAs in association with a multicast address may immediately transmit the Mcst ADDBA response frame according to the Imm- ACK policy. When the same Mcst ADDBA response frame is received several times, the recipients respond to this only one time.

[66] According to one aspect of the present embodiment, the Mcst ADDBA response frame may further include information on a maximal buffer size of available recipients for multicast traffic. By doing so, each recipient can inform the originator of a maximal size of a multicast data packet (data burst) that can be received at once without having to transmit a block ACK frame. This is used when a maximal burst size is determined in subsequent step S33.

[67] As such, when the Mcst ADDBA request frame is transmitted several times (e.g., mMcstlnitNumber times) and the expiration time of the timer (e.g., mMcs- tlnitTimeout) is over, it is regarded that the originator recognizes members of the multicast group. By using information on a buffer size included in the Mcst ADDBA response frame transmitted from the recipients, the originator determines the maximal burst size allowed in the transmission of the multicast data packet (step S33). For the maximal burst size, a minimal buffer size may be selected by using received buffer size information. However, the present invention is not limited thereto.

[68] Subsequently, the originator transmits the Mcst ADDBA request frame several times (e.g., mMcstlnitNumber times) to the recipients (step S34). Similar to the Mcst ADDBA request frame transmitted in step S31, the Mcst ADDBA request frame transmitted in this step has a destination address which is set to a multicast group address. In addition, to ensure successful reception, transmission is performed several times. However, unlike the Mcst ADDBA request frame of step S31, the Mcst ADDBA request frame in this step further includes a buffer size subfield, which is set to the burst size determined in step S33, and a setup subfield which is set to T. The setup subfield indicates that specific information is contained in the buffer size subfield. In addition, the setup subfield indicates that a multicast data packet is ready to be transmitted after step S34.

[69] The originator starts to transmit the multicast data (step S35). In this step, the transmission of the multicast data is performed according to a conventional multicast procedure. In addition, a size of the transmitted data packet cannot exceed a value indicated by the buffer size subfield of the ADDBA request frame transmitted in step S34.

[70] Upon successfully receiving the multicast data, each recipient transmits a Block

ACK (B-ACK) frame for the received multicast data to the originator.

[71] Next, a procedure for participating some new stations, which are included in the multicast group but not included in a multicast block ACK group, to a conventional multicast block ACK group will be described in brief. This procedure is performed when a new station wants to reliably receive existing multicast traffic. To this end, like in step S32, the new station transmits to an originator a multicast block ACK setup response (e.g., Mcst ADDBA response) frame according to a conventional response procedure (e.g., Imm-ACK policy). Upon receiving the Mcst ADDBA response frame from the new station, the originator recognizes that the station is registered to the multicast block ACK group.

[72] According to one aspect of the present embodiment, information on a buffer size of a new recipient may be further included in a multicast block ACK setup response frame transmitted from the new recipient to the originator. If the information on a maximal buffer size is not included in the Mcst ADDBA response frame transmitted from the new recipient to the originator, the originator may additionally transmit, to the new recipient, unicast traffic for requesting the information on the maximal buffer size of the recipient.

[73] Once the originator recognizes the information on the maximal buffer size of the new recipient according to the aforementioned manner, the buffer size information is used to determine the maximal burst size (see step S33). For example, the originator may compare a predetermined maximal burst size with the maximal buffer size of the new recipient, and thus may determine a smaller value as a new maximal burst size. Upon determining the new maximal burst size, as described in step S34, the originator transmits to the recipient a buffer size subfield and a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) several times. Herein, the multicast block ACK setup request frame includes a destination address field which is set to a multicast address, a buffer size subfield which is set to a newly determined maximal burst size, and a setup field which is set to T. Thereafter, multicast data transmission can begin as described in step S35.

[74] Next, a procedure will be described in brief, in which a registered station is deregistered from a multicast block ACK group according to an embodiment of the present invention. When the station is deregistered from the multicast group, the station transmits to an originator a Mcst leave management frame according to the Imm-ACK policy by using a conventional 802.11 standard. The originator may exclude the station from the multicast group of the originator, which will be described in below.

[75] Next, a multicast process performed in an infra- structured Basic Service Set (BSS) mode will be described according to an embodiment of the present invention. The infra-structured BBS may be simply referred to as BBS.

[76] Generally, in the BBS mode, an originator transmits data to a recipient by using either a direct multicast method or an indirect multicast method. In the direct multicast method, the originator transmits data directly to the recipient. In the indirect multicast method, the originator transmits data to the recipient via an AP. In the indirect multicast method in which data is transmitted to the recipient via the AP, a ToDS field of a transmission frame is set to T.

[77] When using the direct multicast in which the originator can deliver data directly to all multicast recipients, the originator can manage its group in the same manner as in an Independent BBS (IBBS) mode (or ad-hoc mode). That is, the originator can manage a multicast block ACK group according to the procedure described in detail with reference to Fig. 3.

[78] When using the indirect multicast in which the recipients can receive traffic only through the AP, the originator may manage its group by transmitting all management frames including a ToDS bit which is set to T. All pieces of multicast data may be transmitted through the AP, which causes an additional overhead. In this case, only the multicast originator transmits its own traffic to the AP by using unicast transmission, and the AP relays traffic by multicast. That is, only the AP is a transmitter of multicast data.

[79] As such, in the infra- structured BBS mode, when a non-AP STA is an originator of multicast data, the multicast data can be transmitted by using either the direct multicast method or the indirect multicast method. However, it is not possible for the non-AP STA to continuously transmit the multicast data by using the direct multicast method. This is because a hidden station may result in a problem when the direct multicast method is used. Therefore, when the originator of the multicast data is the non-AP STA, it is preferable that the originator first checks whether there is an opportunity for directly managing the multicast group and then transmits the data by using the direct multicast method only when the direct management is possible. In order to check whether the direct management is possible, the originator may use the following method, which is only an example.

[80] First, the originator transmits a multicast block ACK setup request frame (e.g.,

Mcst ADDBA request frame), in which a ToDS field is set to '0', several times (e.g., mMcstlnitNumber times). Since the ToDS field is set to '0', the transmission of the Mcst ADDBA request frame corresponds to direct transmission. Thereafter, by using unicast transmission, the originator transmits to an AP a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) including a ToDS bit (set to T) several times (e.g., mMcstlnitNumber times), and the AP retransmits the received multicast block ACK setup request frame to stations of the multicast group several times (e.g., mMcstlnitNumber times). In this case, since the ToDS field of the frame transmitted by the originator is set to T, the transmission of the Mcst ADDBA request frame corresponds to indirect transmission.

[81] After performing the aforementioned direct transmission and indirect transmission, the originator determines whether the number of stations that respond to the originator is constant for each transmission method. If the determination result shows that the number of stations is constant for the two methods, a hidden node problem does not occur. Thus, the originator recognizes that the multicast group can be directly managed. In this case, the originator transmits the multicast data by using the direct transmission method. On the other hand, if the number of stations that respond to the originator is different between the direct transmission and the indirect transmission, the originator selects the indirect transmission. In this case, the originator may report a member list of the multicast block ACK group to the AP by using a special Mcst group announcement frame.

[82] According to one aspect of the present embodiment, while the procedure for generating the multicast block ACK group is performed, a potential multicast recipient may be in a power-save mode or in a switch off state. The potential multicast recipient may intend to be registered to the multicast block ACK group some time later. In this case, if the potential recipient corresponds to a hidden node with respect to the originator and if the originator transmits a multicast frame by using the direct transmission method, then the potential recipient may not be able to be registered to the multicast block ACK group.

[83] Therefore, there is a need for a method for allowing the potential recipient to be able to be registered to the multicast block ACK group. For this, according to the present embodiment, the originator may periodically transmit a Mcst probe request frame including a ToDS field (set to T). In response thereto, a new recipient transmits a multicast block ACK setup response frame (e.g., Mcst ADDBA response frame) including a ToDS field (set to T) to the originator via the AP. Upon receiving the multicast block ACK setup response frame from the new recipient, the originator recognizes the new recipient as a member of a multicast block ACK group of the originator, and transmits multicast traffic to the new recipient via the AP.

[84] When the originator determines to enlist the new recipient to the multicast block

ACK group, a buffer size of the recipient may be less than a predetermined multicast burst size. In this case, by using the indirect transmission method, similar to step S34, the originator may transmit a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) including a setup field (set to T) mMcstlnitNumber times, so that a burst size of the new recipient is set to a buffer size for a corresponding multicast block ACK service.

[85] Meanwhile, in this case, there is a change in a recipient of multicast traffic transmitted from the originator via the AP. Therefore, the originator may report a member list of a multicast group to the AP by using the Mcst group list announcement frame several times.

[86] The following description is related to an operation performed by an originator to achieve reliable multicast transmission in which collision and interference can be avoided between transmission frames. The operation is carried out under different network conditions as follows.

[87] 1) The originator is a non-AP STA in an IBSS (or ad-hoc network) mode, and, among recipients registered to a multicast block ACK group, there is no recipient having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator does not exist).

[88] 2) The originator is a non-AP STA in an IBSS (or ad-hoc network), and, among recipients registered to a multicast block ACK group, there is one or more recipients having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator exists).

[89] 3) The originator is an AP in a BBS mode or a non-AP STA in the BBS mode, and, among recipients registered to a multicast block ACK group, there is no recipient having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator does not exist).

[90] 4) An indirect multicast method is used in which a multicast traffic is transmitted via an AP.

[91] 5) The originator is a non-AP STA in a BBS mode, and, among recipients registered to a multicast block ACK group, when there is one or more recipients having a neighboring station hidden from the originator, multicast traffic is transmitted by using a direct multicast method (i.e., a neighboring station of a recipient hidden from the originator exists, and multicast traffic is transmitted by using the direct multicast method).

[92] (1) Direct Multicast Procedure - When a recipient does not have a neighboring station hidden from an originator.

[93] A direct multicast procedure according to an embodiment of the present invention will now be described for the above network conditions 1) and 3), that is, when a multicast is performed between STAs (or between an STA and an AP) which can perform direct communication with each other and when there is no recipient having a neighboring station hidden from the originator.

[94] In the aforementioned network conditions, all traffic recipients directly communicate with the originator, and there is no station hidden from the originator. Therefore, according to the present embodiment, the originator may transmit only one RTS frame for one or more arbitrary recipients corresponding to a leader. It is not necessary to choose the leader in this manner if an RTS noise-induced error probability is significantly small. In addition, when choosing the leader, the leader may be randomly chosen.

[95] I) RTS-I Procedure [96] Fig. 4 is a message flow diagram for illustrating an RTS-I procedure according to an embodiment of the present invention. Herein, the RTS-I procedure includes an RTS/CTS frame exchange procedure and a multicast frame transmission procedure. Steps S42 to S45 shown in the left portion of Fig. 4 show the case where the originator has received a CTS frame from a leader in response to an RTS frame. Steps S46 to S47 shown in the right portion of Fig. 4 show the case where the originator has failed to receive the CTS frame from the leader. Now, the RTS- 1 procedure according to the present embodiment will be described with reference to Fig. 4.

[97] Referring to the left portion of Fig. 4, before multicast traffic is transmitted, the originator chooses a leader of a multicast group from recipients Rl, R2, and R3 registered to the multicast group (or multicast block ACK group) including a plurality of STAs (step S41). There is no particular restriction in the selection of the leader. In the present embodiment, the recipient Rl is assumed to be chosen as the leader. The originator transmits to the leader RI a unicast RTS frame including a Network Allocation Vector (NAV) which is set to a proper time value (step S42). Upon successfully receiving the RTS frame, the leader Rl transmits a CTS frame in response to the received RTS frame (step S43). According to the present embodiment, since there is no recipient having a neighboring station hidden from the originator, all STAs which are registered to the multicast group can listen the exchange of the RTS/CTS frame. Upon receiving the CTS frame, the originator starts to transmit multicast data (step S44). In this case, HiddenThresholdCounter and McstExclusionCounter related to the current leader Rl are reset to '0' (step S45).

[98] Referring to the right portion of Fig. 4, the originator transmits an RTS frame to the leader Rl. In this case, the originator cannot receive a CTS frame, which is a response frame for the RTS frame, from the leader. If this is the case, according to the present embodiment, the originator performs backoff on multicast data to be transmitted, and increments HiddenThresholdCounter related to the current leader (step S46). When the HiddenThresholdCounter reaches an arbitrary threshold, e.g., mHiddenThreshold, the originator performs an active scan process in which a hidden terminal (to be described below) is actively searched for (step S47).

[99] The multicast data transmission performed in step S44 may fail due to interference or fading. Therefore, even when the method of Fig. 4 is used, there is a need to check whether the multicast data has been successfully transmitted with respect to each STA registered to the multicast group. The checking process can be performed without restriction. For example, a block ACK request frame (e.g., Block ACK Request (BAR) frame) may be transmitted to all multicast frame recipients immediately after multicast frame(s) are transmitted,

[100] 2) ACK Procedure [101] Fig. 5 is a message flow diagram illustrating an ACK procedure according to an embodiment of the present invention. The ACK procedure will now be described with reference to Fig. 5.

[102] After transmitting multicast data, an originator sequentially transmits a BAR frame to all recipients (step S51). Upon receiving the transmitted multicast data, the recipients transmits a Block ACK (B-ACK) frame to the originator in response to the received BAR frame (step S52). If a B-ACK frame is received from a specific recipient, the originator resets McstExclusionCounter related to the specific recipient to '0' (step S53). On the other hand, if no B-ACK frame is received from the specific recipient, the originator increments McstExclusionCounter related to the specific recipient (step S54). In this case, the McstExclusionCounter reaches a predetermined threshold (e.g., McstExclusionCounter threshold), the originator excludes the recipient from the multicast group (step S55).

[103] Then, the originator prepares frames for next burst transmission, wherein the frames include data frames which are not acknowledged by all recipients, and for this, the originator performs backoff. All of non-acknowledged data frames, each of which packet lifespan is not yet expired, may be retransmitted in a next transmission round by the originator. During the burst transmission, new frames and the retransmitted frames may exist in the same burst.

[104] Fig. 6 is a view for explaining a multicast transmission procedure according to an embodiment of the present invention, when there is no recipient having a neighboring station hidden from an originator. The RTS- 1 procedure and the ACK procedure respectively illustrated in Fig. 4 and Fig. 5 are included in the procedure of Fig. 6. Further, the procedure of Fig. 6 includes an RTS-CTS exchange procedure for reliable multicast transmission, a multicast data transmission procedure, and an ACK procedure. The procedure of Fig. 6 shows a case in which three or more recipients are registered to a multicast block ACK group, and one RTS leader exists. The RTS leader is an originator that transmits a CTS frame. Further, the RTS leader is a station that is in charge of RTS-CTS frame exchange. The three recipients are stations to which BAR is transmitted by the originator. The stations respond to the BAR by sending B-ACK.

[105] Referring to Fig. 6, the multicast procedure according to the present embodiment includes an RTS/CTS frame exchange procedure performed one time by using unicast traffic, a multicast data transmission procedure using multicast traffic, and a BAR/ B-ACK exchange procedure performed a plurality of times (corresponding to the number of recipients registered to the multicast block ACK group) by using unicast traffic.

[106] In the present embodiment, the originator performs the RTS-CTS exchange procedure with respect to one RTS leader. Further, the originator transmits a plurality of pieces of data by multicast and thereafter exchanges the BAR and B-ACK frames with three recipients. However, the present invention is not limited thereto. For example, according to another aspect of the present embodiment, the originator may exchange the RTS/CTS frame with the RTS leader. Further, the originator may transmit a plurality of pieces of data and thereafter exchange the BAR frame and the B-ACK frame with all stations belonging to the multicast block ACK group. In another embodiment of the present invention, the originator may exchange the RTS/CTS frame with all stations belonging to the multicast group and may exchange the BAR frame and the B-ACK frame with at least one of stations belonging to the multicast group.

[107] As such, according to the present embodiment, the originator exchanges the RTS/

CTS frame or the BAR/B-ACK frame with at least one of stations belonging to the multicast group, thereby improving reliability in multicast data transmission.

[108]

[ 109] (2) Indirect Multicast

[110] In the present embodiment, it is noted that an AP that relays multicast traffic can listen from all stations existing within a BBS. The following data burst transmission method is proposed in the present embodiment.

[I l l] 1 ) Indirect Multicast Procedure

[112] Fig. 7 is a message flow diagram illustrating an indirect multicast procedure according to an embodiment of the present invention. The indirect multicast procedure will be described hereinafter with reference to Fig. 7.

[113] Referring to Fig. 7, an originator is an STA which is one component of the BBS and transmits an RTS frame including a destination address field that is set to a multicast address and a ToDS field that is set to T (step S61). Since the ToDS field is set to T, the RTS frame is first transmitted to an AP. The AP responds to the received RTS frame by sending a CTS frame (step S62).

[114] After the RTS/CTS frame is exchanged between the originator and the AP, the originator transmits a group of data frames (i.e., data burst) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S63). Upon completing the transmission of the data burst, the originator transmits a block ACK request frame (e.g., BAR frame) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S64). The AP responds to the BAR frame by sending a block ACK frame (e.g., B-ACK frame) (step S65). In the above process, if some of the data frames are damaged or if the B- ACK frame is incorrectly received, the originator repeats steps S61 to S65 after performing backoff.

[115] After receiving the multicast burst by performing the aforementioned processes, the AP performs a multicast procedure according to the present embodiment in the same manner as the aforementioned direct multicast procedure. More specifically, by using the multicast group member list obtained from the multicast group list announcement frame, the AP performs multicast transmission according to the RTS-I procedure of Fig. 4 and the ACK procedure of Fig. 5.

[116] As described above, in the indirect multicast transmission procedure according to the present embodiment, the RTS/CST frame exchange procedure and the multicast burst transmission procedure are performed between the originator and the AP. Thereafter, the RTS-I procedure and the block ACK procedure are performed by regarding the AP as the originator. That is, multicast data is transmitted from the originator to the AP, and then the AP transmits the received multicast data for STAs registered to the multicast group. In this case, a time for transmitting a multicast data packet to the AP may be greater than a time for transmitting the packet from the AP to all multicast recipients. Thus, there is a high probability of packet loss when a lifespan of the packet expires while the packet is transmitted from the AP to all of the recipients.

[117] Accordingly, to address such a problem, it is assumed that an immediate block

ACK policy (e.g., Imm-ACK policy) is used in the indirect multicast procedure according to the present embodiment. In response thereto, the AP sends a block ACK frame and thereafter ensures reliable transmission of the data burst. However, according to the present embodiment, there is a disadvantage in that an originator that initially transmits the multicast data cannot recognize a packet loss even if a packet is lost while the packet is multicast from the AP.

[118] 2) Modified Indirect Multicast Procedure

[119] According to another embodiment of the present invention, a modified indirect multicast procedure is proposed. This is to allow an originator to recognize packet loss when a packet is lost and to improve end-to-end reliability.

[120] Fig. 8 is a message flow diagram illustrating an indirect multicast procedure modified according to another embodiment of the present invention. The modified indirect multicast procedure will now be described with reference to Fig. 8. The modified indirect multicast procedure proposed in the present embodiment employs a delayed block ACK method.

[121] Referring to Fig. 8, an originator is an STA which is one component of the BBS and transmits an RTS frame including a destination address field that is set to a multicast address and a ToDS field that is set to T (step S71). Since the ToDS field is set to T, the RTS frame is first transmitted to an AP. The AP responds to the received RTS frame by sending a CTS frame (step S72).

[122] After the RTS/CTS frame is exchanged between the originator and the AP, the originator transmits a set of data frames (i.e., data burst) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S73). Upon completing the transmission of the data burst, the originator transmits a block ACK request frame (e.g., BAR frame) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S74).

[123] By using the multicast group member list obtained from the multicast group list announcement frame transmitted by the originator, the AP performs multicast transmission according to the RTS-I procedure of Fig. 4 and the ACK procedure of Fig. 5 (step S75). Subsequently, according to a delayed B-ACK policy, the AP transmits the block ACK frame to the originator (step S76).

[124] According to the modified indirect multicast procedure, a data burst is transmitted to STAs which are recipients of multicast data, and in response thereto, the AP sends a block ACK frame to the originator. Therefore, by using the block ACK frame transmitted from the AP, the originator can recognize whether transmitted multicast data packets are correctly transmitted to all recipients or whether some of the packets are lost. If multicast transmission is not successful, for example, when some packets of data burst are not transmitted to all recipients, the originator may report this to a higher layer and/or may start retransmission of a corresponding packet.

[125]

[126] (3) Direct Multicast - When there is a recipient having a neighboring station hidden from an originator.

[127] An embodiment of the present invention to be described hereinafter relates to the aforementioned network conditions 2) and 5). In the network conditions 2) and 5), there are one or more recipients having neighboring stations (hidden nodes) hidden from the originator. As such, in the presence of the hidden nodes, to avoid collision and interference of frames, the originator has to know whether all recipients of multicast data are ready to receive the multicast data.

[128] According to the present embodiment, the following method is proposed which extends a protocol used in the aforementioned case (1) "Direct Multicast Procedure - When a recipient does not have a neighboring station hidden from an originator." More specifically, in this embodiment, allocation of a plurality of (or at least one) RTS- leaders is proposed. The RTS-leaders are chosen as recipients having at least one neighboring station (i.e., hidden node) hidden from the originator. Furthermore, the originator transmits a unicast RTS frame to all RTS-leaders chosen before multicast data is transmitted.

[129] 1) RTS-2 Procedure

[130] 1. An originator sequentially transmits a unicast RTS frame to all RTS-leaders.

[131] 2. If the RTS frame is properly received, the RTS-leaders respond to this by transmitting a CTS frame. [132] 3. If the originator properly receives the CTS frame from a current RTS-leader, the originator resets McstExclusionCounter related to that RTS-leader to '0', and transmits the RTS frame to another RTS-leader (if it exists) or starts multicast transmission.

[133] 4. If the originator fails to properly receive the CTS frame from the RTS-leader in response to the RTS frame, the originator increments McstExclusionCounter related to that RTS-leader. When the McstExclusionCounter reaches McstExclusionCounter threshold, the originator excludes the recipient from the multicast group. Thereafter, the originator performs backoff.

[134] After transmitting the multicast data, the originator performs the ACK procedure shown in Fig. 5.

[135] Fig. 9 is a view for explaining an RTS-CTS exchange procedure, a multicast data transmission procedure, and an ACK procedure, each of which is performed for reliable multicast data transmission when there is a recipient having a neighboring station hidden from an originator as described above. In Fig. 9, recipients for receiving multicast data are three STAs, and among them, two recipients have at least one neighboring station hidden from the originator. In this case, according to an embodiment of the present invention, the originator may choose the two STAs having hidden nodes as RTS-leaders.

[136] Referring to Fig. 9, a multicast procedure according to the present embodiment includes an RTS/CTS frame exchange procedure which is performed two times by using unicast traffic, a multicast data transmission procedure which is performed by using multicast traffic, and a BAR/B-ACK exchange procedure which is performed a plurality of times (corresponding to the number of recipients registered to a multicast block ACK group) by using unicast traffic. The RTS/CTS frame exchange procedure is performed two times between the originator and an RTS-leader having a hidden node. In principal, the RTS/CTS frame exchange procedure is carried out by the same number of times as the number of RTS-leaders having hidden nodes. Mode for the Invention

[137] Hereinafter, some aspects of an embodiment of the present invention will be described.

[138] According to one aspect of the present embodiment, if some recipients have already checked that all frames included in a data burst are received, the originator does not transmit block ACK request frames (e.g., BAR frames) to these recipients. Therefore, in the present embodiment, an ACK overhead can be reduced.

[139] According to the aforementioned block ACK procedure described with reference to

Fig. 5, an originator has to receive a B-ACK frame from each station. However, when the B-ACK frame is received from each station, time delay may be relatively long. Due to such problem, it may not be proper to allow the B-ACK frame to be received from each recipient, in particular, for some applications (e.g., real time streaming for wireless TV) used by many recipients. Therefore, when using applications susceptible to delay, there is a need to address a delay problem caused by a B-ACK procedure performed for each recipient.

[140] According to one aspect of the present invention, a data burst decreases, and the aforementioned block ACK procedure is modified. For example, in another embodiment of the present invention, the B-ACK procedure may be modified in the following manner.

[141] First, a multicast data transmitter (i.e., an originator in the case of direct multicast and an AP in the case of indirect multicast) collects packet loss statistics with respect to N recipients. According to the present embodiment, the packet loss statistics are collected without any restriction. When transmitting a data burst, the transmitter transmits BARs to Nl recipients (where Nl is a natural number greater than or equal to 1) having the highest packet loss probability and N2 recipients (where N2 is a natural number greater than or equal to 0) which are randomly chosen from remaining recipients other than the Nl recipients.

[142] This method may be performed with some alterations. For example, to achieve a minimal delay, the number Nl and N2 may be set to Nl=I and N2=0 or vise versa. In addition, according to one aspect of the present embodiment, a burst size can be limited to one packet. However, reliability may not be sufficiently ensured in this manner.

[143] In order to achieve a maximal reliability and an effective throughput, the above condition may be set to N1<N and N2=N-N1, and a plurality of packets may be set to the data burst. In consideration of a delay limit, a reliability requirement, and a stream start delay, it is possible to optimize Nl, N2, and the burst size.

[144] Now, a method of determining optimal transmitters in a simulation scenario with respect to a hot spot and a narrow ring will be described according to simulation experimentations.

[145] Fig. 10 illustrates a simulation scenario in a hot spot. In Fig. 10, recipients are uniformly distributed in a hot spot zone and operate under different conditions due to a path loss phenomenon.

[146] Fig. 11 illustrates a simulation scenario in a narrow ring. In Fig. 11, all recipients have almost the same Signal-to-Noise Ratio (SNR).

[147] Table 7 shows a simulation environment for a simulation scenario in a hot spot and a narrow ring illustrated in Fig. 10 and Fig. 11.

[148] Table 7

[149] Indices indicating performance and reliability include an M-bit throughput per second in a payload, an average transmission time (e.g., an average time for a packet service), an Average Percent of Packet Losses (APPL), and a Maximal Percent of Packet Losses (MPPL).

[150] Two sources of a packet loss are as follows.

[151] I) A packet is discarded by an originator at a retry threshold.

[152] 2) Recipients, which are not ACK leaders, do not properly receive a packet whereas all current ACK leaders successfully receive the packet.

[153] By using a MATLAP simulation model widely known in the art, a ratio of Packet

Error Rate (PER) to SNR is estimated. A transmitting-side station in the simulation model includes a variable rate data source block, a modulator bank block, an Orthogonal Frequency-Division Multiplexing (OFDM) frame assembler block, an Inverse Fast Fourier Transform (IFFT) block, an OFDM frame multiplexing block. A receiving- side station in the simulation model includes an OFDM frame demultiplexing block, an FFT block, a frequency domain equalizing block, an OFDM frame de-assembler block, and a demodulator bank block. The PER is computed by using the output of the variable rate data source block of the transmitting-side station and the output of the demodulator bank block of the receiving-side station. The SNR is estimated by using the demodulator bank block of the receiving- side station.

[154] Table 8 shows a simulation result obtained by using the aforementioned simulation model in a hot stop. [155] Table 8

[156] In Table 8, M denotes the number of recipients. SNR is 26dB in the center of the hot spot. [157] Fig. 12 and Fig. 13 are graphs showing simulation results related to a throughput with respect to an average transmission time in a hot spot scenario. In Fig. 12 and Fig. 13, the higher the number M of recipients, the higher the PER experienced by ACK leaders, resulting in the increase in the number of retires. As a result, an average transmission time and a throughput decrease.

[158] Fig. 14 and Fig. 15 are graphs showing simulation results related to an average percent of packet losses and a maximal percent of packet losses in a hot spot scenario. In Fig. 14 and Fig. 15, the higher the number of recipients, the higher the packet loss probability. In addition, reliability becomes higher along with the decrease in the throughput.

[159] As shown in Table 8, and Fig. 12 to Fig. 15, optimization can be achieved by fixing the number of ACK leaders. For example, when the number of ACK leaders is fixed to N1+N2, for optimization, Nl may be set to a total number of ACK leaders and N2 may be set to '0'.

[160] Table 9 shows a simulation result by using the simulation model in a ring scenario. [161] Table 9

[162] In the ring scenario, SNR is about 22dB. When Nl and N2 are fixed, APPL remains the same state for all cases. However, at the cost of N2, the increase in Nl results in the increase in MPPL. If Nl=O, all recipients operate in the same conditions, and thus have the same reliability. If N2=0, a reliable ARQ mechanism is provided to fixed ACK leaders while a best effort service is provided to other recipients.

[163] Fig. 16 and Fig. 17 show simulation results related to a throughput and an average transmission time in a ring scenario. In Fig. 16 and Fig. 17, the throughput and the average transmission time are independent from the number of recipients, and very slightly depend on a ratio of N1/N2 along with fixed N1+N2. Fig. 18 and Fig. 19 show simulation results related to an average percent of packet losses and a maximal percent of packet losses in a ring scenario. As shown in Table 9 and Fig. 16 to Fig. 19, the best result is obtained by randomly choosing all ACK leaders (e.g., Nl=O).

[164] Next, a contention-free transmission according to an embodiment of the present invention will be described.

[165] According to another aspect of the present embodiment, an intensive control mode may be used so that an RTS/CTS frame exchange procedure is prevented from being performed several times. The intensive control mode may be either a Point Coordination Function (PCF) or a Hybrid coordination function Controlled Channel Access (HCCA), but the present invention is not limited thereto. If a multicast originator does not coincide with an AP, the multicast originator transmits a specific request to the AP. In response to the request, the AP may allocate a contention-free time period for multicast data transmission (including BAR and B-ACK frames).

[166] Next, a procedure of using Transmission Opportunity (TXOP) will be described according to an embodiment of the present invention. When backoff can be avoided between multicast data bursts, overhead can be further decreased. Details thereof are well known to those skilled in the art, and thus descriptions thereof will be omitted.

[167] Next, hidden terminal detection according to an embodiment of the present invention will be described.

[168] According to one aspect of the present embodiment, for implementation of reliable multicast, it is very important to recognize hidden terminals. When it is recognized that there is no hidden node, multicast data transmission is possible after an RTS/CTS frame is exchanged with only one recipient. This is because the RTS/CTS frame is very short, and thus packet loss probability (caused by noise) can be negligible. However, in general, a multicast transmitter has to assume that all recipients may have neighboring stations hidden from the transmitter, and an RTS frame has to be transmitted to all recipients, which leads to significant overhead.

[169] If the transmitter recognizes the existence of only one recipient having a neighboring station hidden from the transmitter, the transmitter may transmit the RTS frame only to that recipient. If there are two recipients having hidden neighboring stations, it is enough to transmit only two RTS frames to the two recipients. In general, the originator/transmitter can transmit RTS frames without deterioration in reliability only to recipients having neighboring stations hidden from the originator/transmitter. Thus, overall RTS/CTS overhead can be reduced by recognizing hidden terminals.

[170] A hidden terminal may be detected in the following manner.

[171] 1) Passive Scan

[172] Although an originator receives an RTS frame transmitted from a station A to a station B, the originator may not receive a CTS frame which is transmitted in response thereto after a Short Inter-Frame Space (SIFS). This is because the station B is hidden from the originator. The same may also occur when the originator receives a data frame transmitted from the station A to the station B but does not receive ACK transmitted in response thereto after SIFS. Such a method for detecting a hidden terminal is called a passive scan.

[173] Since a wireless channel is not reliable, a threshold (i.e., mHiddenDetectThreshold) is introduced. For example, continuously, if RTSs are received without CTSs or if data frames are received without ACKs, the originator may conclude that a multicast recipient has at least one hidden neighboring station.

[174] However, during an observation time period, there may be no traffic between the station A and the station B. In this case, the passive scan is not sufficient, and thus another technique called an active scan may be used.

[175] 2) Active Scan

[176] According to an active scan, an originator transmits a special InitProbe command including a list of all recipients to all (or some) of the recipients. In response to this command, the recipients transmit probe packets based on the Imm-ACK policy to neighboring stations which are not present in the list. For example, information on the neighboring stations may be obtained by exchanging hello messages defined in an ad- hoc routing protocol.

[177] If the originator receives the probe packets but does not receive ACK after SIFS, the originator may conclude that a corresponding recipient has a hidden neighboring station. If the originator does not receive the probe packet from the recipient, the originator may exclude the recipient from the multicast group. Such an active scan procedure may be periodically performed when HiddenThresholdCounter reaches mHiddenThreshold, as described above in step S47 of Fig. 4. [178] Although exemplary embodiments of the present invention have been described with reference to the drawings, the present invention is not limited thereto.

[179] In the aforementioned embodiments, for multicast group administration including generation, registration, and deregistration of a multicast group (i.e., block ACK multicast group), a block ACK request frame (e.g., Mcst ADDBA request frame) that is a new action frame has been proposed. However, this is for exemplary purpose only, and thus another type of frame format may be used as long as multicast group administration can be carried out in the same manner.

[180] In the aforementioned embodiments, in order to achieve reliable multicast, an access method based on existing ARQ is partially provided as a background, analysis there of is performed under various conditions, and effectiveness thereof is determined. However, the present invention also apply to the case where a plurality of access methods based on existing ARQ are combined or where some features thereof are selected to be combined.

[181] In addition, a new MAC tool is introduced to provide reliable multicast. In particular, according to an embodiment of the present invention, a new mechanism is proposed which manages a multicast group and transmits multicast data in a reliable and effective manner.

[182] In the aforementioned embodiment of the present invention, a station and an AP have been described as an example, wherein the station is equipped with a wireless network interface card and performs operations of physical and MAC layers based on an IEEE 802.11 standard, and wherein the AP performs a wired/wireless interconnection bridge function that relays a frame from one station to another. However, this is for explanation purpose only, and thus, the present invention is not limited thereto.

[183] In addition, since the AP includes physical and MAC layers which are basically the same as those of the station, the AP can perform the same operation as the station. Thus, optionally, the AP may be regarded as the same as the station.

[184] Although it has been described in the aforementioned embodiments that data is transmitted between stations belonging to a specific multicast group by using multicast, the present invention is not limited thereto. Thus, data may be transmitted to stations, which are not specified in an applicable range, by using broadcast. For example, the present invention can improve reliability of broadcast data transmission while reducing overload, since the originator performs exchange of RTS and CTS or exchange of BAR and B-ACK with at least one of the stations.

[185] A wireless Local Area Network (LAN) system has been described in the aforementioned embodiments as an example. Further, the present invention may also apply to a wireless network system including the wireless LAN system and may be im- plemented by combining the two systems or by using a totally different system. In addition, although the wireless network system may exist alone in the present invention, the wireless network system may inter-work with another wireless network system, a mobile communication network, a wired/wireless Internet, and so on.

[186] For example, a wireless LAN system may provide a roaming service by inter- working with a mobile communication network (e.g., a Wideband Code Division Multiple Access (WCDMA) network). Specifically, when the wireless LAN system provides a voice service, a Dual Band Duel Mode (DBDM) terminal that supports both wireless LAN and WCDMA can continuously perform automatic roaming by using the wireless LAN system in a region where the wireless LAN system is supported while a voice call is provided by using the mobile communication network.

[187] While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the appended claims. Industrial Applicability

[188] The present invention is effectively used in a network device, a network protocol, and a user device, each of which is related to wireless communication.

Claims

[1] A multicast method in a wireless network, comprising the steps of: transmitting, by a first station, a plurality of data frames in which a destination address field is set to an address of a specific multicast group; and performing a block acknowledgment (ACK) procedure between one or more second stations registered to the multicast group and the first station.

[2] The multicast method of claim 1, wherein the step of performing a block ACK procedure comprises: transmitting, by the first station, a block ACK request frame to the second station; and transmitting, by the second station, a block ACK response frame which indicates whether the plurality of data frames are successfully received in response to the block ACK request frame.

[3] The multicast method of claim 2, wherein the block ACK procedure is performed by unicast, and wherein the block ACK procedure is performed with respect to all stations registered to the multicast group or is performed with respect to only one or more stations.

[4] The multicast method of claim 1, further comprising, prior to the step of transmitting a plurality of data frames, ensuring a channel between one or more third stations registered to the multicast group and the first station.

[5] The multicast method of claim 4, wherein the ensuring of a channel comprises exchanging a Request To Send (RTS) frame and a Clear To Send (CTS) between the first station and the third station.

[6] The multicast method of claim 4, wherein members of the multicast group do not have neighboring stations hidden from the first station, and the third station is any one of stations selected from the members of the multicast group.

[7] The multicast method of claim 4, wherein the members of the multicast group have one or more fourth stations having neighboring stations hidden from the first station, and the third station includes all of the fourth stations.

[8] A multicast method in a wireless network, comprising the steps of: transmitting, by a first station, a first multicast block acknowledgement (ACK) setup request frame in which a destination address field is set to an address of a specific multicast group; and transmitting, by a second station which belongs to members of the multicast group and intends to use a block ACK mechanism in a multicast service, a multicast block ACK setup response frame to the first station in response to the first multicast block ACK setup request frame. [9] The multicast method of claim 8, further comprising: transmitting, by the first station, a plurality of data frames in which a destination address field is set to an address of a multicast block ACK group including the second station; and transmitting, by the second station, a block ACK frame after the plurality of data frames are all received. [10] The multicast procedure of claim 8, wherein the multicast block ACK response frame includes information on a maximal buffer size that can be used by the second station, and further comprising: determining a maximal burst size of data that is multicast in a subsequent step by using information on the maximal buffer size by the first station receiving the multicast block ACK response frame; and transmitting, by the first station, a second multicast block ACK setup request frame which includes the maximal burst size and in which a destination address field is set to an address of a specific multicast group. [11] The multicast procedure of claim 10, further comprising: multicasting, by the first station, a data frame having a data size less than or equal to the maximal burst size; and transmitting, by the second station, a block ACK frame to the first station. [12] A multicast method in a wireless network, comprising: selecting one or more recipient stations from members of a multicast group by an originator station that intends to transmit multicast data; performing a channel ensuring procedure by using unicast traffic between the originator station and the selected recipient station; transmitting, by the originator station, the multicast data in which a destination address field is set to an address of the multicast group; and performing a block ACK procedure on the transmitted multicast data between the originator station and the selected recipient station. [13] The multicast method of claim 12, wherein all of the members of the multicast group do not have neighboring stations hidden from the originator station, and the selected recipient station is any one of stations belonging to the members of the multicast group. [14] The multicast method of claim 12, wherein one or more stations selected from the members of the multicast group have neighboring stations hidden from the originator station, and the selected recipient station includes the one or more stations.