KR20080016420A - Communication method in wireless network, communication method and station in wireless network - Google Patents

Abstract

A communication method in a wireless network, a communication method of a station in a wireless network, and a station are provided to transmit multicast data reliably. An originator transmits a multicast ADDBA(ADD Block Ack) including a destination address field with a set multicast address and a setup field set by 0 by mMcstInitNumber of times(S31). Stations(Recipients) which are intended to receive multicast data transmit multicast ADDBA responses according to an Imm-ACK(Immediate Block Ack) policy(S32). The originator sets a maximum burst size as a minimum buffer size among information regarding a buffer size included in the multicast ADDBA responses(S33). The originator transmits a multicast ADDBA request including the multicast address-set destination address field, the buffer size-set buffer size sub-field and a setup field set by 1 by mMcstInitNumber of times(S34). The originator starts multicast data transmission(S35).

Description

COMMUNICATION METHOD IN A WIRELESS NETWORK, COMMUNICATION METHOD OF A STATION IN THE WIRELESS NETWORK, AND THE STATION}

1 is a diagram illustrating a format of a general management frame;

2 is a view illustrating a frame control field of FIG. 1;

3 is a view for explaining a multicast group management method according to an embodiment of the present invention;

4 is a view for explaining an RTS-1 procedure according to an embodiment of the present invention;

5 is a view for explaining an ACK procedure according to an embodiment of the present invention;

6 is a view for explaining an indirect multicast procedure according to an embodiment of the present invention;

7 is a view for explaining a modified indirect multicast procedure according to another embodiment of the present invention;

8 illustrates a simulation scenario in a hot spot.

9 shows a simulation scenario in a narrow ring;

FIG. 10 illustrates a MATLAP simulation model of IEEE 802.11a for estimating Packet Error Rate (PER) vs. Signal-to-Noise Ratio (SNR). FIG.

11 is a diagram showing a simulation result regarding a transmission rate and an average transmission time in a hot spot;

12 shows the simulation results related to the average percentage of packet loss and the maximum percentage of packet loss at hot spots,

FIG. 13 is a diagram showing simulation results related to throughput and average transmission time in a ring scenario; and

FIG. 14 is a diagram showing simulation results related to an average percentage of packet loss and a maximum percentage of packet loss in a ring scenario.

The present invention relates to a wireless network communication method for multicast group management and reliable multicast transmission, a communication method of a station in a wireless network, and a station.

In addition, as the wireless network environment is rapidly spreading recently, various broadcast or multicast services have been proposed in the wireless network.

An object of the present invention is to provide a multicast method for managing a multicast group and reliably transmitting multicast data.

Technical problems to be achieved by the present invention are not limited to the above-mentioned technical problems, and other technical problems not mentioned above may be clearly understood by those skilled in the art from the following description. There will be.

According to an aspect of the present invention, there is provided a method of communicating in a wireless network, the method comprising: transmitting, by one station, a multicast group creation request including a multicast address; And at least one other station receives the multicast group creation request and transmits or does not transmit a response to the multicast group creation request to the one station.

A communication method in a wireless network according to an embodiment of the present invention includes transmitting a multicast group creation request including a multicast address; And receiving or not receiving a response to the multicast group creation request from at least one other station.

In a wireless network according to an embodiment of the present invention, a communication method of a station comprises: receiving a multicast group creation request including a multicast address from one other station; And transmitting or not transmitting a response to the multicast group creation request to the one other station.

A station according to an embodiment of the present invention transmits a multicast group creation request including a multicast address to at least one other station.

Receive a multicast group creation request including a multicast address from one other station according to an embodiment of the present invention, and do not transmit or send a response to the multicast group creation request to the other other station. .

According to another aspect of the present invention, a communication method in a wireless network includes: transmitting, by one station, a Request To Send (RTS) to at least one other station among stations belonging to a multicast group; And the at least one other station receiving the RTS and transmitting a clear to send (CTS) to the one station; And transmitting, by the one station and the stations belonging to the multicast group, multicast data to each other.

In another embodiment of the present invention, a communication method of a station in a wireless network includes transmitting a request to send (RTS) from at least one station to at least one other station belonging to a multicast group; Receiving, by the one station, a clear to send (CTS) from the at least one other station receiving the RTS; And transmitting and receiving the multicast data with stations belonging to the multicast group by the one station.

A station according to another embodiment of the present invention transmits a Request To Send (RTS) to at least one other station among stations belonging to a multicast group, and receives a Clear To Send (CTS) from the at least one other station. Then, the multicast data is transmitted and received with the stations belonging to the multicast group.

A communication method in a wireless network according to an embodiment of the present invention includes the steps of transmitting, by one station, multicast data to other stations belonging to a multicast group by multicast; Transmitting, by the one station, a block ACK request to at least one other station among other stations belonging to the multicast group; And when the at least one other station receives or does not receive the block ACK request from the one station and receives the block ACK request from the one station, transmitting a block ACK to the one station. Include.

In a wireless network according to an embodiment of the present invention, a communication method of a station may include transmitting, by one station, multicast data to other stations belonging to a multicast group by multicast; Transmitting, by the one station, a block ACK request to at least one other station among other stations belonging to the multicast group; And the one station receiving or not receiving a block ACK from at least one other station among other stations belonging to the multicast group.

A station according to an embodiment of the present invention transmits multicast data to other stations belonging to a multicast group by multicast, and requests a block ACK from at least one station among other stations belonging to the multicast group. Request), and at least one station receives or does not receive a block ACK from it.

Hereinafter, with reference to the drawings will be described embodiments of the present invention; Hereinafter, embodiments of the present invention will be described using a wireless LAN system as an example of a wireless network system. However, embodiments of the present invention will be substantially the same in the same or allowable range as the WLAN system in the range allowed or supported in various wireless network systems other than the WLAN system. In addition, the terms or words used in the embodiments of the present invention may be used as other terms or words in various wireless network systems, but the present invention may be used when the actual meaning is the same or similar despite the differences between the terms or words. It is included in the scope of the invention.

Multicast is a bandwidth-conserving technology that reduces traffic by delivering a single data stream to multiple recipients simultaneously.

Applications that use multicast include videoconferencing, corporate communication, distance learning, distribution of software, stock quotes, and news. have. In wireless home networking, multicast can be used in gaming and streaming sharing applications.

Another approach is to require the source to send a separate copy of the data to each receiver. This will increase the application traffic by the number of receivers. Thus, this direct alternative, not to mention in video conferencing and the like, is bandwidth consuming, even in low traffic applications.

Multicast is based on the concept of a group of recipients interested in a particular data stream. Stations interested in receiving data flowing to a particular group should join the group. At the MAC layer, multicast groups are characterized by multicast MAC addresses. The stream sender transmits a packet having a destination address field set to a multicast MAC address. All members of the group receive the packet. In multicast transmission, the stream sender does not need to copy packets individually and transmit them separately for each station.

It is assumed that a layer higher than the MAC layer is responsible for creating, joining, leaving, and changing multicast groups. In the current IEEE 802.11 version these issues are out of scope.

There is no error recovery mechanism (ARQ) for multicast traffic in IEEE 802.11. Since RTS / CTS exchange is prohibited in the case of multicast, multicast is not protected from collision. Multicast does not guarantee that data is delivered completely and reliably. Since the probability of frames being lost from interference, collision, or time-varying channel increases, the reliability of multicast traffic is reduced compared to the reliability of unicast traffic. In fact, for this reason, it is difficult to envision bandwidth conservation for multicast in most cases.

The purpose of reliable multicast is to ensure that all group members are subject to various conditions (for example, in both basic service set (BSS) mode and independent basic service set (IBSS) mode, or in noise and hidden stations). All multicast packets must be successfully received.

Protocols that make multicast transmissions more reliable and efficient are described.

In Reference 1 (Joy Kuri, Sneha Kumar Kasera, "Reliable Multicast in Multi-access Wireless LANs," 1999 IEEE.), Three general protocols for reliable multicast in multi-access wireless LANs have been proposed. That is, one reader-based protocol (Leader-Based Protocol (LBP)), two protocols based on random timers and probabilistic measurements (Delayed Feedback-Based Protocol (DBP), Probabilitic Feedback-Based Protocol (PBP) )) Has been proposed.

These protocols are all designed for the case where the base station is the originator.

The Leader-Based Protocol (LBP) assumes that one of the recipients of the multicast data has been selected as the leader. The leader is responsible for providing CTS and ACK in response to the entered RTS and data packets. Other recipients are responsible for transmitting only negative CTSs (NCTSs) and negative ACKs (NAKs).

In the Delayed Feedback-Based Protocol (DBP), when the receiver listens to the RTS, all receivers delay the CTS transmission to reduce the likelihood of a collision. This delay is chosen randomly from the time slots from 1 to L. If the CTS frame is not heard before the delay timer expires, the device transmits the CTS frame. In the Delayed Feedback-Based Protocol (DBP), only NAK confirmation policy is applied.

Probabilitic Feedback-Based Protocol (PBP) is similar to the Delayed Feedback-Based Protocol (DBP). The only difference is that in Probabilitic Feedback-Based Protocol (PBP), devices have only one time slot for CTS transmission, instead of waiting for any number of slots to transmit CTS. . All devices must transmit a CTS in a slot that conforms to the RTS with a certain probability.

These three protocols are inefficient when there is a hidden station because CTS reception from one station does not guarantee that the other station is not associated with a collision. Likewise, when one station responds with an ACK, this does not mean that all other stations receive the multicast packet correctly because the interference may be different.

In Reference 2 (Min-Te Sun, Lifei Huang, Anish Arora, Ten-Hwang Lai, "Reliable MAC Layer Multicast in IEEE 802.11 Wireless Networks," Proc. Of the International Conference on Parallel Processing (ICCP'02)), 1 (B) Broadcast Media Window (BMW), 2) Broadcast Support Multiple Access (BSMA), and 3) Batch Mode Multicast MAC (BMMM).

Broadcast Support Multiple Access (BSMA) is described in K. Tang and M. Gerla, "Random Access MAC for efficient Broadcast Support in Ad Hoc Networks," Proc. IEEE WCNC 2000, pp. 454-459, Sep. 2000. Was first proposed. This protocol uses the conventional RTS / CTS scheme of the IEEE 802.11 Distributed Coordination Function (DCF) for multicast. According to this approach, all multicast receivers transmit CTS frames immediately after the RTS frame is received, and the proponent of the BSMA protocol relies on the capture effect to resolve the CTS collision. In addition, the BSMA protocol introduces a NAK frame to indicate that the data frame has been collided.

In the case of broadcast support multiple access (BSMA), the probability of CTS collision is very high. The capture effect can't help much in solving crash problems. As a result, there is a very large overhead because many retries are required with increasing backoffs. In addition, even if the sender successfully receives the CTS from one of the receivers, there is no guarantee that due to the presence of the hidden station, no collision will occur at the other station.

In Reference 4 (K. Tang and M. Gerla, "MAC Reliable Broadcast in Ad Hoc Networks," Proc. IEEE MILCOM 2001, pp. 1008-1013, Oct. 2001.), BMW provides a reliable broadcast MAC. The protocol is introduced.

The basic idea behind the BMW protocol is to treat each broadcast request as a number of unicast requests. In the BMW (Broadcast Media Window), the sender uses at least n rounds of DCF-style unicast transmissions for multicast requests intended for n neighboring nodes. Each round requires one contention phase before the RTS frame is transmitted.

BMW implies that n RTSs are sent to each station. All RTSs follow a competitive phase. Thus, there are many backoffs for each multicast packet. In addition, unusual RTS, CTS, and ACK frames are assumed. Since the multicast data packet follows the intended RTS at only one station, if there is a hidden station, the other station may be involved in the collision. Thus, data transmission is not protected from collision.

In Reference 2, BMMM (Batch Mode Multicast MAC) integrates BMW's n contention phases into one. The multicast sender sends unicast RTSs to all devices in the multicast group. If the caller does not receive the CTS from any of the devices in the multicast group, the caller delays the transmission and enters a contention phase. When the originator receives the CTS from any of the devices in the multicast group, the sender sends multicast data frames to all devices, and subsequently sends a request for an ACK frame (RAK) to all devices. do.

BMMM is a more reliable protocol than BMSA and BMW. BMMM differs from BMW in that it sends RTSs for all stations before sending multicast data packets. However, the overhead of BMMM increases with the number of recipients. Even with fewer recipients, the overhead present in RTSs, CTSs, RAKs, and ACKs is greater than the multicast packets themselves.

Most of the protocols described above imply that the number of multicast group members is known. For example, in the BMMM and BMW protocols, the number of multicast group members corresponds to the number of RTS / CTS and the number of RAK / ACK. In the Leader Based Protocol, it is assumed that a leader is selected from a multicast group so that device lists in the multicast group are known. To provide reliable multicast, the multicast sender will recognize the multicast group members at the MAC layer.

Indeed, in the current version of IEEE 802.11, there is no mechanism for creating and managing multicast groups. The present invention seeks to provide an efficient tool for creating, joining, leaving, and maintaining multicast groups. The present invention also addresses the problem of hidden terminals and provides a method for reducing traffic overhead compared to BMMM. Overall, the present invention proposes a reliable multicast transmission scheme that combines the high reliability of the BMMM protocol with the high throughput, delay efficiency of the reader-based protocol.

1. Manage multicast groups ( Multicast Group management )

(1) multicast block  Confirm( Multicast block acknowledgment )

After all packet transmissions, in order to reduce the very large overhead of BMMM (Batch Mode Multicast MAC) which includes the transmission of multiple ACKs, in this embodiment it is recommended to use the block acknowledgment scheme introduced in IEEE 802.11e. Suggest.

To initiate the block acknowledgment transmission mode, the originator sends an Add Block Ack (ADDBA) request to the recipient, which responds with an ADDBA response. However, legacy IEEE 802.11 requires only unicast addresses in these action frames.

1 is a diagram illustrating a format of a management frame of IEEE 802.11.

Referring to FIG. 1, a management frame includes a frame control, a duration, a destination address, a source address, a basic service set identifier, a sequence control, and a sequence control. , Frame body, and FCS.

FIG. 2 illustrates the frame control field of FIG. 1.

Referring to FIG. 2, the frame control field includes the following subfields. That is, the frame control field includes protocol version, type, subtype, To DS, From DS, More Fragment, Retry, Power Management, More Data, Web, and Order. Subfields such as (Order).

Among these, types and subtypes indicate the function of a frame. By type, it is divided into three frames: control frame, data frame, and management frame. Each frame type has several defined subtypes.

Table 1 below defines valid combinations of types and subtypes.

Type value b3 b2 Type description Subtype value b7 b6 b5 b4 Subtype description 00 Management 0000 Association request 00 Management 0001 Association response 00 Management 0010 Reassociation request 00 Management 0011 Reassociation response 00 Management 0100 Probe request 00 Management 0101 Probe response 00 Management 0110-0111 Reserved 00 Management 1000 Beacon 00 Management 1001 Announcement traffic indication message (ATIM) 00 Management 1010 Diassocation 00 Management 1011 Authentication 00 Management 1100 Deauthentication 00 Management 1101 Action 00 Management 1110-1111 Reserved 01 Control 0000-0111 Reserved 01 Control 1000 Block Ack Request (BlockAckReq) 01 Control 1001 Block Ack (BlockAck) 01 Control 1010 Power Save Poll (PS-Poll) 01 Control 1011 Request To Send (RTS) 01 Control 1100 Clear To Send (CTS) 01 Control 1101 Acknowledgement (ACK) 01 Control 1110 Contention-Free (CF) -End 01 Control 1111 CF-End + CF-Ack 10 Data 0000 Data 10 Data 0001 Data + CF-Ack 10 Data 0010 Data + CF-Poll 10 Data 0011 Data + CF-Ack + CF-Poll 10 Data 0100 Null (no data) 10 Data 0101 CF-Ack (no data) 10 Data 0110 CF-Poll (no data) 10 Data 0111 CF-Ack + CF-Poll (no data) 10 Data 1000 QoS Data 10 Data 1001 QoS Data + CF-Ack 10 Data 1010 QoS Data + CF-Poll 10 Data 1011 QoS Data + CF-Ack + CF-Poll 10 Data 1100 QoS Null (no data) 10 Data 1101 Reserved 10 Data 1110 QoS CF-Poll (no data) 10 Data 1111 QoS CF-Ack + CF-Poll (no data) 11 Reserved 0000-1111 Reserved

Since the ADDBA request and the ADDBA response defined in IEEE 802.11i correspond to the management frame, they are transmitted in the frame format shown in FIG. 1. In this case, since the type field has a value of '00' and the subtype corresponds to 'action', the subtype field has a value of '1101'.

In addition, the ADDBA request includes information as shown in Table 2 below in the frame body.

Referring to Table 2, the frame body of the ADDBA request includes category, action, dialog token, block ACK parameter set, block ACK timeout value, and block ACK starting sequence control. The category field is set to '3', which represents a block ACK, and the action field is set to '0', representing a value of an ADDBA request.

In addition, the ADDBA response includes information as shown in Table 3 below in the frame body.

Referring to Table 3, the frame body of the ADDBA response includes a category, an action, a dialog token, a status code, a block ACK parameter set, and a block ACK timeout value. The category field is set to '3' which is a value indicating a block ACK, and the action field is set to '1' which is a value indicating an ADDBA response.

This embodiment is similar to unicast, but allows the use of multicast addresses as the recipient's address and includes a new action frame, Multicast ADDBA Request and Multicast ADDBA Response, which may include additional fields. It is proposed to introduce Mcst ADDBA Response.

The new action frame proposed by the present invention, the multicast ADDBA request and the multicast ADDBA response, are used to manage a multicast group, including group creation, participation, and withdrawal.

The action frames of the multicast ADDBA request and the multicast ADDBA response include the action frames of the ADDBA request and the ADDBA response described above with reference to Tables 1-3. The fields of can be used as they are in the required range, newly defined in the appropriate range, or not used.

For example, the type field of the frame control field has a value of '00', and since the subtype corresponds to 'action', the subtype field has a value of '1101'. The category field and the action field may use reserved values.

In addition, the data burst size can be set using a new action frame, a multicast ADDBA request and a multicast ADDBA response, and uses a multicast address as a recipient address. . In addition, the multicast ADDBA request and the multicast ADDBA response may include additional fields such as a setup field.

In the embodiment of the present invention, the newly defined multicast ADDBA request may include information as shown in Table 4 in the frame body.

Order Information One Category (4: Multicast Block Ack) 2 Action (0: Multicast ADDBA Request) 3 Dialog Token 4 Multicast Block Ack parameter Set 5 Multicast Block Ack Timeout Value 6 Multicast Block Ack Starting Sequence Control

Referring to Table 4, the multicast ADDBA request may include a category, an action, a dialog token, a multicast block Ack parameter set, a multicast block Ack timeout value, and a multicast block Ack starting sequence control. The category field may be set to '4', which indicates a multicast block Ack, and the action field may be set to '2', which indicates a multicast ADDBA request.

Similarly, the multicast ADDBA response newly defined in the present invention may include information as shown in Table 5 in the frame body.

Order Information One Category (4: Multicast Block Ack) 2 Action (1: Multicast ADDBA Response) 3 Dialog Token 4 Status Code 5 Multicast Block Ack parameter Set 6 Multicast Block Ack Timeout Value

Referring to Table 5, the multicast ADDBA response may include a category, action, dialog token, status code, multicast block Ack parameter set, and multicast block Ack timeout value. The category field may be set to '4', which indicates a multicast block Ack, and the action field may be set to '1', which indicates a multicast ADDBA response.

In addition, the multicast delta (BA) for terminating the block Ack may include the information shown in Table 6 in the frame body.

Order Information One Category (4: Multicast Block Ack) 2 Action (2: Multicast DELBA) 3 Multicast DELBA paremeter set 4 Reason code

Referring to Table 6, the multicast delta may include a category, an action, a multicast delta parameter set, and a reason code. The caterogi field may be set to '4', which indicates a multicast block Ack, and the action field may be set to '2', which indicates a multicast delta.

(2) Multicast group management Multicast group management ) -IBSS ( Independent  Basic Service Set ) mode  Or direct multicast

It is assumed that the multicast address is selected in the higher layer. Multicast addresses are known for multicast senders and potential recipients. Before sending multicast data, the sender creates a multicast group and matches the maximum data burst size with all group members. In general, the sender will not belong to a multicast group, but may be a station belonging to a multicast group.

In this embodiment, the following multicast group management scheme is proposed.

1) Create / Manage Multicast Group ( Multicast group creation / management)

3 is a view for explaining a multicast group management method according to an embodiment of the present invention.

Referring to FIG. 3, the sender transmits a multicast ADDBA Request (Mcst ADDBA Request) including a destination address field with a multicast address set to 0 and a setup field set to 0 using normal 802.11 rules (S31). ). The reason for sending mMcstInitNumber times for multicast ADDBA Requests is that, if a sender sends a multicast ADDBA request only once, it is not possible for all receivers to be sure that they have correctly received the multicast ADDBA request sent by the sender. to be. The sender starts the timer after sending the last multicast ADDBA Request. The expiration period of the timer is mMcstInitTimeout.

Upon receiving such a frame, stations intended to receive multicast data receive a multicast ADDBA response according to the Imm-ACK policy (Immediate Block Ack policy: the receiver responds with a BlockAck frame to a BlockAckReq frame if this policy is used). Respond with (Mcst ADDBA Response) (S32). When receiving the same multicast ADDBA Request multiple times, the stations only respond once. At this time, the multicast ADDBA response includes information on the maximum buffer size of the receivers available for multicast traffic.

If all of the multicast ADDBA Requests are sent, and the mMcstInitTimeout has elapsed, the sender is considered aware of the members of the multicast group. The sender sets the maximum burst size to the minimum buffer size among the information about the buffer size included in the multicast ADDBA Responses of the receivers using typical IEEE 802.11 rules (S33).

The sender sends a Mcst ADDBA request including a destination address field with a multicast address set, a buffer size subfield with a burst size set, and a setup field set to '1' in mMcstInitNumber times (S34). The reason for sending mMcstInitNumber times for multicast ADDBA Requests is that, if a sender sends a multicast ADDBA request only once, it is not possible for all receivers to be sure that they have correctly received the multicast ADDBA request sent by the sender. to be.

Thereafter, the sender may start multicast data transmission (S35).

2) Join or join a multicast group Multicast group joining )

If some new station wants to receive existing multicast traffic reliably (for example, to join an existing multicast group), the new station can use the Imm-Ack policy (Immediate) using the usual 802.11 rules. Multicast ADDBA Response (Mcst ADDBA Response) frame is transmitted to the stream sender according to Block Ack policy).

In this case, the multicast ADDBA response transmitted by the new receiver to the stream sender may include information about the buffer size of the new receiver. If the multicast ADDBA Response sent by the new receiver to the stream sender does not contain information about its maximum buffer size, the sender may request a new receiver to request information about the receiver's maximum buffer size. Cast traffic can be sent.

In this way, when the sender knows the information about the maximum buffer size of the new receiver, the sender compares the burst size already set with the maximum buffer size of the new receiver and sets a smaller value to the new burst size.

When the new burst size is set, the sender sends a multicast ADDBA request including a destination address field with a multicast address set, a buffer size subfield with a burst size set, and a setup field set to '1' as in step S34. After sending (Mcst ADDBA Request) mMcstInitNumber times, it will start multicast data transmission as in step S35.

3) Leave the Multicast Group ( Multicast group leaving )

If the station leaves the multicast group, the station will send a Multicast Leave Management Frame to the stream sender according to the Imm-ACK policy using conventional 802.11 rules. The sender can exclude the station from his multicast group, which will be described later.

(3) Multicast group management Multicast group management ) -BSS ( Basic Service  Set) mode

In BSS mode, there are two ways for the sender to send data to the receiver.

That is, there are two methods, a direct multicast method in which a sender transmits data directly to a receiver, and an indirect multicast method in which data is transmitted to a receiver through an access point. In the indirect multicast method of transmitting data to the receiver through the access point, the ToDS bit is set to '1'.

In the case of direct multicast where the caller can reach all multicast recipients directly, the sender can manage his group in the same way as in Independent Basic Service Set (IBSS) mode (or ad-hoc mode). . That is, the caller may manage the group in the manner described in FIG. 3 described above.

In indirect multicast, where the recipients can only receive traffic through the access point, the sender can manage the group by sending all management frames containing the ToDS bit set to '1'. At this time, all multicast data may be transmitted through the access point incurring additional overhead.

In this case, only the multicast sender transmits its own traffic to the access point using unicast transmission, and the access point relays the traffic using multicast. That is, only the access point becomes a multicast sender.

To see if there is an opportunity to manage the group directly, the caller can use the following two steps.

In the first step, the sender transmits a multicast ADDBA Request Frame with the ToDS bit set to '0' (mcst ADDBA Request Frame) mMcstInitNumber times (direct transmission).

In the second step, the sender transmits a multicast ADDBA Request Frame including the ToDS bit set to '1' to the access point by mMcstInitNumber times using unicast transmission (indirect transmission).

The access point retransmits the multicast ADDBA Request to the stations of the multicast group by mMcstInitNumber times using conventional multicast transmission. Stations that respond to the caller during the first phase will not respond in the second phase.

After performing the first and second steps, if the number of stations responding to the caller is the same, the caller may recognize that he or she can manage the group directly. Thus, in this case, the sender will transmit the multicast data in a direct transmission manner.

After performing step 1 and step 2, if the number of stations responding to the sender is not the same, and the sender chooses indirect transmission, the sender may select the multicast group through a special Multicast Group List Announcement Frame. The access point will be notified of the member list.

However, during the multicast group creation procedure, the potential multicast receiver may be in sleep mode or switched off. Later, the potential receiver may want to subscribe, but if the potential receiver is hidden from the sender and multicast data is sent directly from the sender, the potential receiver will not be able to join the multicast group.

To allow this potential recipient to subscribe, the sender may periodically send a Multicast Probe Request frame containing a ToDS bit set to '1'.

In response, the new receiver sends a multicast ADDBA Response Frame to the sender via the access point, including the ToDS bit set to '1'. Upon receiving a multicast ADDBA Response frame from the new receiver, the sender accepts the new receiver as a member of its multicast group and sends multicast traffic to the new receiver via the access point.

Also, if the sender decides to accept a new receiver, and the receiver's buffer size is less than the multicast burst size, then the sender uses a conventional 802.11 rule to request a multicast ADDBA request that includes a setup field set to '1'. By sending (Mcst ADDBA Request) mMcstInitNumber times, we will set the burst size to the receiver's buffer size.

Since the caller decides to redirect the multicast traffic via the access point, the caller will notify the access point of the member list of the multicast group via the Multicast Group List Announcement Frame. .

2. Reliable multicast transmission Reliable multicast transmission)

The following describes what actions the sender will perform for reliable multicast transmission under different network conditions as follows.

1) The sender is located in the IBSS (or ad-hoc network) and the neighbors of the receiver (hidden) hidden from the sender do not exist.

2) The sender is located in the IBSS (or ad-hoc network) and there is one or more neighbors of (hidden) hidden from the sender.

3) The originator is the BSS's access point or BSS terminal station, and there is no hidden (hidden) neighbor from the originator for all recipients.

4) Indirect multicast when multicast traffic is transmitted via an access point.

5) Direct multicast in which the sender is a BSS terminal station and at least one receiver with at least one neighbor hidden (hidden) from the sender.

(1) hidden from the sender ( Hidden)  Receiver's neighbor does not exist ( No  recipient's neighbors hidden from the originator )

First, the present embodiment describes a case where multicast is performed between the network conditions 1) and 3) described above, that is, devices which can directly communicate with each other, and there are no neighbors of the receiver (hidden) hidden from the sender. .

In this case, this embodiment proposes to use a modified BMMM (Batch Mode Multicast MAC) protocol. When all the recipients communicate directly with the sender and cannot hear any station (hidden) hidden from the sender, the sender can only send one RTS intended for any recipient (leader). When the RTS noise-induced error probability is very small, this reader selection is not essential. For example, the leader can be chosen randomly.

In this embodiment, we propose a modification of the BMMM protocol with a reader-based approach as follows.

One) RTS -1 procedure ( RTS -One procedure)

4 is a diagram for explaining an RTS-1 procedure according to an embodiment of the present invention. 4, the RTS-1 procedure according to an embodiment of the present invention will be described.

1. Before transmitting the frame (s), the sender selects the RTS-reader of the multicast group (S41).

2. The sender will transmit a unicast RTS including the Network Allocation Vector (NAV) set to the appropriate time to the RTS reader (S42).

3. If the RTS leader receives the correct RTS, the RTS-Reader will respond with a CTS (S43).

4. Upon receiving the CTS, the sender will start multicast data transmission (S44). At this time, the hidden threshold counter (HiddenThresholdCounter) and the multicast exclusion counter (McstExclusionCounter) associated with the current reader are reset to '0' (S45).

5. If the CTS is not received by the sender in response to the RTS, the sender will perform a backoff procedure and increment the HiddenThresholdCounter associated with the current leader (S46).

6. When the hidden threshold counter (HiddenThresholdCounter) reaches the mHiddenThreshold value, the sender performs a procedure (active scan) to actively search for a hidden terminal (active scan) as described later (S47).

However, there is still a possibility that ongoing multicast transmissions will fail due to interference or fading. Thus, immediately after the transmission of the multicast frame (s), the sender starts sending a Block ACK Request (BAR) frame (see IEEE 802.11e) to all multicast recipients, as proposed in the BMMM protocol.

2) ACK  step( ACK  procedure)

5 is a diagram illustrating an ACK procedure according to an embodiment of the present invention. 5, an ACK procedure according to an embodiment of the present invention will be described.

1. After transmitting the multicast data, the sender starts sending a block acknowledgment (BAR) to all receivers in sequence (S51).

2. All receivers will immediately respond to the BAR frame destined for itself with a block ACK (B-ACK) frame (S52).

3. When the sender receives a block ACK frame from the receiver, the sender will reset the multicast exclusion counter (McstExclusionCounter) associated with the receiver to '0' (S53).

4. If the sender does not receive a block ACK frame from the receiver, the sender will increment the multicast exclusion counter (McstExclusionCounter) associated with the receiver (S54). When the counter reaches the threshold (McstExclusionCounter Threshold), the sender should exclude the receiver from the multicast group (S55).

5. The sender will prepare frame (s) for the next burst transmission, including data frames not identified by all recipients, and perform a backoff procedure. All unidentified frames whose packet lifetime has not expired will be resent by the originator in the next transmission round. During burst transmission, new frames and retransmitted frames may exist in the same burst.

Table 7 below shows RTS-CTS exchange and multicast data for reliable multicast transmission, described with reference to FIGS. 3 and 4, when there is no neighbor of the receiver (hidden) from the sender as described above. Table showing transmission and ACK procedures.

Referring to Table 7, three receivers exist and one RTS leader exists. Here, the RTS leader refers to the station responsible for the RTS-CTS exchange with the sender, and the three receivers are stations to which the BAR is transmitted by the sender, and these stations respond with a block-ACK to the BAR. .

In the above embodiment, the sender exchanges the RTS reader and the RTS-CTS (RTS-CTS exchange), transmits a plurality of data in multicast, and then exchanges the BAR and the block-ACK with three receivers. The present invention is not limited thereto.

That is, the sender exchanges the RTS-CTS with the RTS reader (RTS-CTS exchange), transmits a large number of data in multicast, and then all of the stations corresponding to the multicast group and the sender block the BAR and the block as in the BMMM described above. -ACK can be exchanged. In addition, the caller may exchange RTS-CTS with all of the stations corresponding to the multicast group, and block-ACK with the BAR with at least one of the stations corresponding to the multicast group.

As a result, the sender exchanges block-ACK with at least one of the stations corresponding to the multicast group and the RTS-CTS or the BAR, thereby improving reliability of the multicast data transmission.

(2) indirect multicast ( Indirect multicast )

Note that in this embodiment, an access point relaying multicast traffic can listen to all stations in the BSS. In this embodiment, the following data burst transmission scheme is proposed.

1) Indirect multicast procedure ( Indirect multicast  procedure)

6 illustrates an indirect multicast procedure according to an embodiment of the present invention. 6, an indirect multicast procedure according to an embodiment of the present invention will be described.

1. The sender, which is a BSS terminal station, transmits an RTS frame including a destination address having a multicast address set and a ToDS bit set to '1' (S61).

2. The access point responds with a CTS (S62).

3. The sender transmits a data burst including a destination address having a multicast address set and a ToDS bit set to '1' (S63).

4. The sender transmits a Block Ack Request (BAR) including a destination address having a multicast address set and a ToDS bit set to '1' (S64).

5. The access point responds with a block ACK (S65).

If some data frames appear to be corrupted or the block ACK is not correctly received, steps S61 to S65 are repeated after performing the backoff.

6. Based on the multicast group member list obtained from the Mcst group list guide frame, the access point performs multicast transmission according to the RTS-1 procedure shown in FIG. 4 and the ACK procedure shown in FIG. 5 (S66). .

While a packet is being delivered from an access point to all receivers, it can take more time for the packet to be delivered from the access point to all multicast recipients than to the time it takes to deliver a packet from the multicast sender to the access point. Due to the expiration of the lifetime, there is a high probability of packet loss.

In this indirect multicast procedure, an immediate block ACK policy (Imm-Ack policy) is assumed. After responding with a block ACK, the access point is responsible for better reliability of the burst transmission. Thus, if a packet is lost, the sender does not recognize it.

2) Modified indirect multicast procedure ( Modified indirect multicast procedure )

When a packet is lost, another embodiment of the present invention proposes a slightly modified indirect multicast procedure to improve the end-to-end reliability and to recognize the loss of the packet. do.

FIG. 7 illustrates a modified indirect multicast procedure according to another embodiment of the present invention. FIG. Referring to FIG. 7, a modified indirect multicast procedure according to another embodiment of the present invention will be described.

The modified indirect multicast procedure proposed in this embodiment uses a delayed block ACK scheme.

1. The sender, which is a BSS terminal station, transmits an RTS frame including a destination address having a multicast address set and a ToDS bit set to '1' (S71).

2. The access point responds with a CTS (S72).

3. The sender transmits a data burst including a destination address having a multicast address set and a ToDS bit set to '1' (S73).

4. The sender transmits a Block Ack Request (BAR) including a destination address having a multicast address set and a ToDS bit set to '1' (S74).

5. Based on the multicast group member list obtained from the Multicast Group List Announcement Frame sent by the sender, the access point is shown in FIG. 4 and the RTS-1 procedure shown in FIG. Multicast transmission is performed according to the ACK procedure (S75).

6. The access point sends the BAR to the sender with the delayed B-ACK policy (S76).

Through this modified indirect multicast procedure, the sender can know whether the transmitted packet is normally delivered to all receivers, or part of the packet is lost. If some packets in the burst are not delivered to all recipients, the sender notifies the higher layer of this information or initiates packet retransmission.

(3) direct multicast ( Direct multicast ) -Hidden neighbors ( hidden heihgbors )

The network conditions 2) and 5) described above will be described.

In this case, there are one or more neighbors of the receiver that are hidden (hidden) from the sender. Thus, the sender must know if the receiver (recipients) is ready to receive multicast data. This embodiment proposes the following scheme by extending the protocol applied to "(1) the neighbor of a hidden (hidden) receiver from a sender does not exist".

More specifically, this embodiment proposes to assign multiple (or one in the simplest case) RTS-leaders. RTS-leaders are elected as recipients with at least one neighbor hidden from the sender. The sender will send a unicast RTS to all RTS-readers before the multicast transmission.

One) RTS -2 procedure ( RTS -2 procesure )

1. The sender will send unicast RTS to all RTS-leaders in turn.

2. If the correct RTS is received, the RTS-leaders will respond with a CTS.

3. When the sender receives the correct CTS frame from the current RTS-reader, the sender resets the multicast exclusion counter (McstExclusionCounter) associated with that RTS-reader to zero, and sends the RTS frame to another RTS-reader (if present). Or start a multicast transmission.

4. If the sender does not receive the correct CTS from the RTS-Reader in response to the RTS, the sender will increment the multicast exclusion counter (McstExclusionCounter) associated with that RTS-reader. When the multicast exclusion counter (McstExclusionCounter) reaches a threshold (McstExclusionCounter Threshold), the sender will exclude the recipient from the multicast group. The sender will then perform a backoff procedure.

After multicast data transmission, the sender will perform the ACK procedure shown in FIG.

Table 8 is a table showing the RTS-CTS exchange, multicast data transmission, and ACK procedure for reliable multicast transmission when there is a neighbor of the receiver (hidden) hidden from the sender as described above.

Referring to Table 8, there are three recipients, two of which have at least one neighbor hidden from the sender, so that two RTS-leaders are selected by the sender.

3. Other possibilities Other opportunities )

(One) ACK  Reduce overhead ( ACK overhead reduction )

If some recipients have already acknowledged all the frames in the burst during the previous transmission (s), the sender will not transmit BAR frames to these recipients. This reduces overhead.

According to the ACK procedure described in FIG. 4, receiving an ACK from each station may result in a long delay, particularly not suitable for some applications where there are many receivers (real time streaming for wireless TV). In order to limit stringent delays in such delay-sensitive applications, it is possible to reduce the data bursts (with some loss of reliability) and change the ACK procedure.

Another embodiment of the present invention proposes a change of the ACK procedure in the following manner.

The multicast sender (ie, sender or access point in case of direct or indirect multicast) collects packet loss statistics for each receiver. When transmitting a data burst, the sender sends BARs to the N1 receivers with the highest probability of packet loss and the N2 receivers randomly selected from other receivers.

This approach can be adjusted. For example, to achieve the minimum delay, N1 = 1, N2 = 0, or vice versa can be set, and the burst size can be limited by one packet. But the reliability of this approach is not sufficient.

In order to achieve maximum reliability and an efficient transmission rate, N1 <N, N2 = N-N1 can be set, and a large number of packets can be set in the burst. Considering the delay limit, reliability requirements, and stream start delay, it will be possible to optimize N1, N2, and burst size.

Hereinafter, a method for determining an optimal sender in a simulation scenario in various models, for example, a hot spot and a narrow ring, will be described through a simulation experiment.

8 is a diagram illustrating a simulation scenario in a hot spot. In Fig. 8, the receivers are evenly distributed in the hot spot area and operate under different conditions due to the path loss phenomenon.

9 is a diagram illustrating a simulation scenario in a narrow ring. In Figure 9, all receivers have approximately the same signal-to-noise ratio.

Table 9 is a table showing a simulation environment for the simulation scenarios in the hot spot and narrow ring of FIGS. 8 and 9.

Simulator GPSS World Protocol version 802.11a / e PHY data rate 54 Mbps Maximum number of data packets in a burst 10 Retry threshold 5 Path loss factor 2 SIFS 16 DIFS 34 Channel model AWGN MAC Data frame length, including 2346 bytes Payload length 2312 bytes Operation mode Saturation

The indices of performance and reliability indicate the throughput of M bits per second in payload, average transmission time (eg, average time for packet service), and average percentage of packet loss. Average Percent of Packet Losses (APPL), Maximum Percent of Packet Losses (MPPL).

The two sources of packet loss are:

1) When the retry threshold is reached, the packet is discarded by the sender.

2) Packets are not correctly received by receivers that are not ACK readers, whereas all current ACK readers successfully receive packets.

FIG. 10 illustrates a MATLAP simulation model of IEEE 802.11a for estimating Packet Error Rate (PER) vs. Signal-to-Noise Ratio (SNR).

Referring to FIG. 10, the transmitting station includes a variable rate data source block, a modulator bank block, an OFDM frame assembler block, an IFFT block, an OFDM frame multiplexing block, and the like.

The receiving station also includes an OFDM frame demultiplexing block, an FFT block, a frequency domain equalization block, an OFDM frame deassembler block, a demodulator bank block, and the like.

In the simulation model, the PER was calculated from the output of the variable rate data source block of the transmitting station and the output of the demodulator bank block of the receiving station. In addition, the SNR was estimated from the demodulator bank block of the receiving station.

Table 10 shows a simulation result at the hot spot.

M N1 N2 Average percentage of packet loss ( APPL ) Packet loss Persen ( MPPL ) 20 One 0 0.595 2.26 20 0 One 0.76 2.78 20 2 0 0.407 1.53 20 One One 0.493 1.98 20 0 2 0.658 2.48 20 4 0 0.216 0.63 20 2 2 0.326 1.41 20 0 4 0.528 2.15

In Table 9, M represents the number of recipients. On the other hand, the signal-to-noise ratio (SNR) at the center of the hot spot is 26 dB.

11A and 11B are diagrams showing simulation results regarding a transmission rate and an average transmission time in a hot spot.

11A and 11B, as the number of recipients M increases, the Packet Error Rate (PER) experienced by the N1 ACK readers becomes higher, which leads to an increase in the number of retry attempts. Therefore, the average transmission time and transmission rate decrease.

12A and 12B show simulation results related to the average percentage of packet loss at the hot spot and the maximum percentage of packet loss.

12A and 12B, it can be seen that as the number of receivers increases, the probability of packet loss increases. It can also be seen that higher reliability can be achieved by lowering the transmission rate.

As can be seen from Table 10 and FIGS. 11 to 12, all ACK readers can be fixed and optimized, for example, in the total number of fixed ACK readers N1 + N2, N1 equals this total number. Can be optimized by setting N2 to 0.

Table 11 shows the simulation results in the ring scenario.

M N1 N2 Average percentage of packet loss ( APPL ) Maximum percentage of packet loss ( MPPL ) 10 0 One 1.24 1.41 10 One 0 - 1.57 10 0 2 1.03 1.15 10 One One - 1.24 10 2 0 - 1.37 10 0 4 0.673 0.83 10 2 2 - 0.96 10 4 0 - 1.28

In a ring scenario, the signal-to-noise ratio is approximately 22 dB.

With N1 and N2 fixed, the average percentage of packet loss (APPL) remains the same in all cases. However, at the cost of N2, the maximum percentage of packet loss (MPPL) increases as N1 increases.

In the case of N1 = 0, all receivers operate under the same conditions and thus have the same reliability. In the case of N2 = 0, the fixed ACK readers are provided with a reliable ARQ mechanism, while the other receivers receive only the best effort service.

13A and 13B show simulation results related to throughput and average transmission time in a ring scenario.

In Figures 13A and 13B, the transmission rate and average transmission time are independent of the number of recipients, and very little depends on the N1 / N2 ratio with fixed N1 + N2.

14A and 14B are diagrams showing simulation results related to an average percentage of packet loss and a maximum percentage of packet loss in a ring scenario.

As can be seen from Table 11 and FIGS. 13 and 14, it is best to randomly select all ACK leaders, for example, set N1 = 0.

(2) non-competitive transmission Contention - free transmission )

To avoid multiple RTS / CTS exchanges, centralized control mode (PCF of legacy IEEE 802.11 and HCCA of IEEE 802.11e) can be used. To this end, if the multicast sender and the access point do not match, the multicast sender will send a special request to the access point. In response to this request, the access point may allocate a contention-free period for multicast data transmission (including BAR and B-ACK frames).

(3) TXOP  Tool ( TXOP tool )

To further reduce the overhead, the Transmission Opportunity (TXOP) tool introduced in IEEE 802.11e is used, which allows to avoid backoff between multicast data bursts. The details are replaced by the Transmission Opportunity (TXOP) tool introduced in IEEE 802.11e.

(4) hidden terminal detection ( Hidden Terminal Detection )

It is very important to recognize hidden terminals for reliable multicast implementation. Knowing that there are no hidden terminals, it is possible to send multicast data after having an RTS / CTS exchange with only one of the receivers, because the RTS and CTS frames are very short and their loss probability (due to noise) This can be ignored. In general, however, a multicast sender should assume that all receivers may have hidden (hidden) neighbors from the sender, and send an RTS to all receivers (see, for example, BMMM), which creates a large overhead. Generate.

Here, if the sender knows that there is a unique receiver with one neighbor hidden (hidden) from the sender, the sender can send an RTS frame only to that receiver. If there are two receivers with hidden (hidden) neighbors, it is sufficient to only send two RTS frames to the two receivers. In general, the sender / sender can send an RTS frame only to recipients with neighbors hidden (hidden) from the sender / sender without loss of reliability. This means that recognizing hidden terminals can reduce the total RTS / CTS overhead.

The depressed terminal may be detected as follows.

1) manual search ( Passsive scan )

The sender has received an RTS frame sent from station A to another station B, but may not receive a CTS frame sent in response after a Short InterFrame Space (SIFS), because station B may be hidden from the sender. The same conclusion can be drawn if the sender received a data frame sent from station A to B, but the sender did not receive an ACK sent in response after SIFS. This method for detecting hidden terminals is called manual search.

The wireless channel is unreliable, which is why it introduces a threshold, mHiddenDetectThreshold, for example, when continuously receiving RTSs without corresponding CTSs, or receiving data frames without ACKs, the sender has at least one multicast receiver. It can be concluded that we have hidden (hidden) neighbors.

However, during the observation period, there may be no traffic between station A and station B. In this case, passive scanning is not enough, so another technique called active scan can be used.

2) active search ( Active scan )

By active retrieval, the sender sends a special InitProbe command to each (or part) of the recipients with a list of all recipients included. In response to this command, receivers send probe packets with an Imm-ACK policy to their neighbors that are not in the list. For example, neighbor information can be obtained by exchanging hello messages defined in the ad hoc routing protocol.

If the sender receives probe packets but does not receive an ACK after SIFS, the recipient is assumed to have a hidden terminal if the multicast originator receives a probe packet, but not an ACK a SIFS later), the sender can conclude. If the sender does not receive the probe packet from the receiver, the sender may exclude the receiver from the multicast group.

As described in operation 47 of FIG. 4, the active search procedure may be periodically performed when the HiddenThresholdCounter reaches the mHiddenThreshold value.

As mentioned above, although the embodiments of the present invention have been described with reference to the drawings, the present invention is not limited thereto.

In the above embodiments, a new action frame, a multicast ADDBA request frame, is proposed to manage a multicast group including creation, joining, and withdrawal of a multicast group. However, this corresponds to an embodiment of the present invention. If a multicast group can be managed in the same manner as an ADDBA request, other types of frame formats may be used.

In the above embodiments, some background AR-based approaches have been provided in the background to achieve reliable multicast, analyzed them under various conditions, and concluded on their efficiency. However, the present invention also includes a description of the above-described embodiments of the present invention and the existing ARQ-based approaches combined or extracted by extracting some of the features.

In the above embodiments, a new MAC tool is introduced to make multicast reliable. In particular, embodiments of the present invention propose a new mechanism for managing multicast groups and for reliably and efficiently transmitting multicast data.

In the above embodiments, IEEE 801.11 and IEEE 801.11i, IEEE 801.11e, and the like have been mentioned, but the present invention is not limited to these standards.

In the above embodiments, a station for performing operations of the physical layer and the MAC layer based on the IEEE 802.11 standard by mounting a network interface card for a wireless LAN, and relaying a frame transmitted from one station to another station Although the access point performing the wired / wireless interworking bridge function has been described as an example, the present invention is not limited thereto.

In addition, since the access point basically includes the same physical layer and MAC layer as the station described above, the access point can basically perform the same operation as the station. Thus, the access point may be considered to be the same as the station as needed.

In the above embodiments, it has been described that data is transmitted by multicast between stations corresponding to a specific multicast group, but the present invention is not limited thereto. The present invention may send data by broadcast to stations that are not specified in the applicable range. For example, the present invention can improve the reliability of broadcast data transmission while reducing overload since the sender exchanges block-ACK with at least one of the stations and with RTS-CTS or BAR.

In the above embodiments, the WLAN system has been described as an example, but the present invention includes a wireless network system including a WLAN system, and a combination thereof or a completely different system may be implemented. In addition, although the wireless network system may exist alone, the present invention may interwork with other wireless network systems, mobile communication networks, and wired and wireless Internet networks.

For example, the WLAN system may provide roaming service by interworking with a mobile communication network, for example, Wideband Code Division Multiple Access (WCDMA). Specifically, when the WLAN system provides a voice service, a dual band dual mode (DBDM) terminal supporting both WLAN and WCDMA performs a voice call using a mobile communication network, and then supports the WLAN system. In the WLAN system can be automatically roaming seamlessly.

In the above description of the preferred embodiment of the present invention, the present invention is not limited to the above-described specific embodiment, it is common in the art to which the invention belongs without departing from the spirit of the invention claimed in the claims. Various modifications can be made by those skilled in the art, and such changes are within the scope of the claims.

As described above, the present invention has an effect of managing a multicast group and reliably transmitting multicast data.

Claims (56)

Transmitting, by one station, a multicast group creation request including a multicast address; And At least one other station receiving the multicast group creation request and sending or not sending a response to the multicast group creation request to the one station. The method of claim 1, The multicast group creation request, Multicast address is a multicast ADDBA (ADD Block Ack) request (Mcst ADDBA Request) including a destination address is set, The response to the multicast group creation request is The communication method in a wireless network, characterized in that the multicast ADDBA response (Mcst ADDBA Response) to the multicast ADDBA Request (Mcst ADDBA Request). The method of claim 2, The multicast ADDBA Request (Mcst ADDBA Request) further includes a setup field, The one station sets the setup field to '0' to send the multicast ADDBA request to the other stations, And when the other station receives the multicast ADDBA request, transmits a multicast ADDBA response including its maximum buffer size to the one station. The method of claim 3, The one station receives a multicast ADDBA response including its maximum buffer size from the at least one other station, and then sets a multicast set to the smallest value among the maximum buffer sizes included in the multicast ADDBA responses. Sending to the other station a multicast ADDBA request comprising a maximum burst size of traffic and a setup field set to '1'; The one station further comprises the step of transmitting the multicast data to other stations belonging to the multicast group. The method of claim 4, wherein And among the stations belonging to the multicast group, a station intending to withdraw from the multicast group, further comprises transmitting a multicast leave management frame to another station. The method of claim 2, Include additional access points, The one station transmits a multicast ADDBA request having a ToDS bit set to '1' to the access point by unicast transmission. The access point further comprises transmitting a multicast ADDBA request received from the one station to the at least one other station. The method of claim 6, The one station further comprises transmitting to the access point a multicast group list announcement frame (Mcst Group List Announcement Frame) containing information about the stations belonging to the multicast group; . Transmitting a multicast group creation request including a multicast address; And Receiving or not receiving a response to the multicast group creation request from at least one other station. The method of claim 8, The multicast group creation request, Multicast address is a multicast ADDBA (ADD Block Ack) request (Mcst ADDBA Request) including a destination address field is set, The response to the multicast group creation request is The communication method of a station in a wireless network, characterized in that the multicast ADDBA response (Mcst ADDBA Response) to the multicast ADDBA Request (Mcst ADDBA Request). The method of claim 9, The multicast ADDBA Request (Mcst ADDBA Request) further includes a setup field, Send the multicast ADDBA request to the at least one other station by setting the setup field to '0', And receiving a multicast ADDBA response including its maximum buffer size from another station receiving the multicast ADDBA request. The method of claim 10, After receiving the multicast ADDBA response including the maximum buffer size from the at least one other station, the maximum burst size of the multicast traffic set to the smallest value among the maximum buffer sizes included in the multicast ADDBA responses; Sending a multicast ADDBA request including the setup field set to 1 'to the other station; And transmitting the multicast data to other stations belonging to the multicast group. The method of claim 11, And receiving a Multicast Leave (Mcst Leave) management frame from a station belonging to the multicast group from a station to leave the multicast group. The method of claim 9, Include additional access points, And transmitting a multicast ADDBA request with a ToDS bit set to '1' to the access point in a unicast transmission manner. The method of claim 13, Transmitting to the access point a multicast group list announcement frame including information about stations belonging to the multicast group. Receiving a multicast group creation request including a multicast address from one other station; And Transmitting or not transmitting a response to the multicast group creation request to the one other station. The method of claim 15, The multicast group creation request, Multicast address is a multicast ADDBA (ADD Block Ack) request (Mcst ADDBA Request) including a destination address field is set, The response to the multicast group creation request is The communication method of a station in a wireless network, characterized in that the multicast ADDBA response (Mcst ADDBA Response) to the multicast ADDBA Request (Mcst ADDBA Request). The method of claim 16, The multicast ADDBA Request (Mcst ADDBA Request) further includes a setup field, When receiving the multicast ADDBA request in which the setup field is set to '0' from the other station, a multicast ADDBA response including its maximum buffer size is transmitted to the other station. A communication method of a station in a wireless network, characterized in that. The method of claim 17, Receiving a multicast ADDBA request including a maximum burst size of multicast traffic set to the smallest of the maximum buffer sizes included in the multicast ADDBA responses and a setup field set to '1' from the other station; Step; and Receiving the multicast data from the one other station, wherein the station belongs to a multicast group. The method of claim 18, If it is desired to leave the multicast group, transmitting a multicast leave management frame (Mcst Leave Management Frame) to the one other station. The method of claim 16, Include additional access points, In the wireless network further comprises the step of receiving a multicast ADDBA Request (Mcst ADDBA Request) is set to '1' by the access point received from the one other station from the access point in a unicast transmission method Station communication method. The method of claim 20, The access point receives a multicast group list announcement frame including information of stations belonging to the multicast group from the other station. . A station that transmits a multicast group creation request that includes a multicast address to at least one other station. The method of claim 22, The multicast group creation request, A station characterized in that the multicast address is a multicast Add Block Ack (ADDBA Request) including a destination address field set. The method of claim 23, wherein The multicast ADDBA Request (Mcst ADDBA Request) further includes a setup field, Send the multicast ADDBA request to the at least one other station by setting the setup field to '0', And receive from the at least one other station receiving the multicast ADDBA request a multicast ADDBA response including a maximum buffer size. The method of claim 24, After receiving the multicast ADDBA responses including the maximum buffer size from the at least one other station, the maximum burst size of the multicast traffic set to the smallest of the maximum buffer sizes included in the multicast ADDBA responses; Send a multicast ADDBA request including a setup field set to 1 'to the at least one other station, And transmit multicast data to the other stations belonging to the multicast group. The method of claim 25, And receiving a multicast rib (Mcst Leave) management frame from a station to which the multicast group intends to withdraw from the multicast group. The method of claim 23, wherein Include additional access points, And a multicast ADDBA request having a ToDS bit set to '1' to the access point in a unicast transmission method. The method of claim 27, And transmit a multicast group list announcement frame including information on stations belonging to the multicast group to the access point. Receive a multicast group creation request containing a multicast address from one other station, A station that transmits or does not transmit a response to the multicast group creation request to the one other station. The method of claim 29, The multicast group creation request, Multicast address is a multicast ADDBA (ADD Block Ack) request (Mcst ADDBA Request) including a destination address field is set, The response to the multicast group creation request is And a multicast ADDBA response to the multicast ADDBA request. The method of claim 30, The multicast ADDBA Request (Mcst ADDBA Request) further includes a setup field, Receive a multicast ADDBA request from the one other station with the setup field set to '0', In response to the multicast ADDBA request, transmitting a multicast ADDBA response including its maximum buffer size to the one other station. The method of claim 31, wherein Receive, from the other station, a multicast ADDBA request including a maximum burst size of multicast traffic set to the smallest of the maximum buffer sizes included in the multicast ADDBA responses and a setup field set to '1' and, The station belongs to a multicast group, and receives multicast data from the one other station. 33. The method of claim 32, If it is going to leave the multicast group, it transmits a multicast Leave (Mcst Leave) management frame to the one other station. The method of claim 30, Include additional access points, And a multicast ADDBA Request with the ToDS bit set to '1' received by the access point from the other station, from the access point in unicast transmission. The method of claim 34, wherein The access point is, And receiving a multicast group list announcement frame including information on a station belonging to the multicast group from the other station. Transmitting, by one station, a Request To Send (RTS) to at least one other station among stations belonging to the multicast group; And The at least one other station receiving the RTS and transmitting a clear to send (CTS) to the one station; Transmitting, by the one station and the stations belonging to the multicast group, multicast data to each other. The method of claim 36, If the one station fails to receive the CTS from the at least one other station, performs a backoff procedure and increments a Hidden Threshold Counter associated with the other station. Communication method in The method of claim 36, The other station is an access point, The access point, after exchanging the RTS and the CTS with the one station, receives multicast data from the one station as unicast and transmits the multicast data to other stations belonging to the multicast group by multicast; The one station sending a Block ACK Request to the other stations before transmitting the multicast data in multicast; Sending, by the access point, a block ACK for the block ACK request to the one station before or after transmitting the multicast data to the other stations in multicast. Communication method. Transmitting, by one station, a Request To Send (RTS) to at least one other station among stations belonging to the multicast group; Receiving, by the one station, a clear to send (CTS) from the at least one other station receiving the RTS; And And transmitting, by the one station, multicast data to and from stations belonging to the multicast group. The method of claim 39, If the CTS is not received from the at least one other station, performing a backoff procedure and increasing a Hidden Threshold Counter associated with the other station. The method of claim 39, The other station is an access point, The access point, after exchanging the RTS and the CTS with the one station, receives multicast data from the one station as unicast and transmits the multicast data to other stations belonging to the multicast group by multicast; The one station sending a Block ACK Request to the other stations before transmitting the multicast data in multicast; Sending, by the access point, a block ACK for the block ACK request to the one station before or after transmitting the multicast data to the other stations in multicast. Communication method. Stations belonging to the multicast group after transmitting a request to send (RTS) to at least one other station among the multicast groups, and receiving a clear to send (CTS) from the at least one other station A station that sends and receives multicast data. The method of claim 42, wherein If not receiving a CTS from the at least one other station, perform a backoff procedure and increase a Hidden Threshold Counter associated with the other station. The method of claim 42, wherein The other station is an access point, The access point exchanges an RTS and a CTS with the one station, receives unicast multicast data from the one station, and transmits the multicast data to other stations belonging to the multicast group by multicast. The one station sends a Block ACK Request before transmitting the multicast data to the other stations in multicast, and the access point multicasts the multicast data to the other stations. And receive a block ACK for the block ACK request to the access point before or after transmitting. Transmitting, by one station, multicast data to other stations belonging to the multicast group in multicast; Transmitting, by the one station, a block ACK request to at least one other station among other stations belonging to the multicast group; And And when the at least one other station does not receive or receive the block ACK request from the one station and receives the block ACK request from the one station, transmitting a block ACK to the one station. A communication method in a wireless network. The method of claim 45, And when the one station receives a block ACK from the other station, resets a multicast exclusion counter associated with the other station. The method of claim 45, And if the one station does not receive a block ACK from the other station, increments a Multicast Exclusion Counter associated with the other station. The method of claim 45, At least one of the other stations belonging to the multicast group is at least one of at least one station having a high packet loss probability and at least one station selected at random. One station transmitting multicast data in multicast to other stations belonging to the multicast group; Transmitting, by the one station, a block ACK request to at least one other station among other stations belonging to the multicast group; And And one station receiving or not receiving a block ACK from at least one other station among other stations belonging to the multicast group. The method of claim 49, And when the one station receives a block ACK from the other station, resets the multicast exclusion counter associated with the other station. The method of claim 49, If the one station does not receive a block ACK from the other station, increments a multicast exclusion counter (Mcst Exclsuion Counter) associated with the other station. The method of claim 49, At least one of the other stations belonging to the multicast group is at least one of at least one station having a high packet loss probability and at least one station selected at random. Transmitting multicast data to other stations belonging to the multicast group by multicast, transmitting a block ACK request to at least one of the other stations belonging to the multicast group, and transmitting the at least one A station receiving or not receiving a block ACK from a station. The method of claim 53, Receiving a block ACK from the other station, resetting the multicast exclusion counter associated with the other station. The method of claim 53, If not receiving a block ACK from the other station, increase the Multicast Exclusion Counter associated with the other station. The method of claim 53, At least one station of the other stations belonging to the multicast group is at least one of at least one station having a high packet loss probability and at least one station selected at random.

Images