JP2009207147A - Multicast method in wireless lan - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for performing multicast transmission at media access control (MAC) layer in the wireless network. <P>SOLUTION: The multicast method in the wireless LAN includes: a step for dividing multicast group members into subgroups and indicating the representative node; a step for multicasting MRTS and waiting for MCTS from the representative node; a step for multicasting data packet to multicast group members after receiving MCTS and recording the number of the data packet transmitted; a step for recording a value indicating whether the data packet transmitted this time was received successfully in bit map field of each MCTS after the representative node received data packet and transmitting MCTS after the expected time; and a step for determining presence/absence of data packet loss by the value of the bit map field of MCTS and transmitting the lost data packet at the time of next transmission of the data packet when a packet loss is present. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to a multicast method in a wireless network, and more particularly to a method of performing multicast transmission with high reliability in a wireless LAN. The method performs grouping on a receiving member, and only a representative of each group transmits. By sending feedback information to the side, the delay is reduced, the efficiency of the multicast protocol is increased, and the overhead of the control packet is reduced.

  In wireless broadband access technology, IEEE 802.11 has already become a very popular choice. Currently, many important applications on a wireless LAN are all based on multicast transmission. These applications include, but are not limited to, multimedia conferences, shared whiteboards, distance education, multi-user games and distributed computing.

  Multicast indicates that a data packet is transmitted from one source side to a plurality of destination sides, and a copy of the information is transmitted to a group of addresses, and the information is delivered to all the desired recipients. Compared to unicast, the efficiency of multicast is very high. This saves network bandwidth and resources because every given link is used at most once. Much attention has now been given to the benefits of multicast transmission in terms of resource utilization.

  In wireless broadband access, wireless LAN has become a very popular choice. Regardless of whether it is a home or a company, WLAN is widely applied. Considering this point, there is a high possibility that the last hop of a multicast packet in the Internet is a wireless LAN.

  However, in the current Internet multicast design, everything is usually studied in the backbone network and concentrated on multicast route design and group member management. The WLAN cannot support multicast transmission of the MAC layer. When the access point finds a transmission multicast packet that needs to be transmitted, the access point simply processes it as a broadcast packet. Normally, the media access control (MAC) layer does not consider whether it is a multicast packet. Therefore, the MAC layer does not provide a multicast design and processes data packets as broadcasts. In this case, the following problems occur when multicast packets of the IP layer are transmitted by WLAN. On the other hand, extra IP processing overhead increases. This is because the current MAC layer does not support multicast packets, so a node (station) in a WLAN does not distinguish between multicast packets and broadcast packets received by the MAC layer, and cannot support unsupported multicast packets. After the packet is uniformly transferred to the IP layer, the receiving side determines whether or not to receive the packet by the multicast address. This increases processing overhead that is not required by the IP layer. On the other hand, when multicast packets are transmitted over WLAN, there is no RTS (transmission request packet) / CTS (reception preparation complete packet) handshake alternating mechanism that holds the channel, and there is no retransmission mechanism for error correction. Is lower. Thus, multicast packets can be lost due to link errors or collisions.

  In order to support multicast transmission at the MAC layer, the following three problems should be solved.

  1. How to avoid information conflicts. In order to support retransmission, group receivers send feedback information to the sending node (usually an access point (AP)) to inform whether the information packet has been received correctly. When multiple nodes transmit feedback information at the same time, collisions are likely to occur at the AP.

  2. How to reduce control packet overhead. To support reliable transmission, the multicast protocol needs to use control packets such as RTS (transmission request packet), CTS (reception ready packet), ACK (acknowledgment). In the case of unicast, the overhead of the control packet is not so high, but in the case of multicast, if all the group members transmit RTS, CTS and ACK, the overhead of the control packet is very large.

  3. How to adjust the transmission speed. Unicast transmission in WLAN supports self-adaptive speed adjustment on the transmitting side. When the channel condition is good, the transmission side increases the transmission rate, and vice versa. Since there are multiple receiving nodes in multicast transmission, the channel conditions may change completely. When adjusting the self-adaptive speed, the channel conditions between the AP and the receiving nodes Should be considered.

  In addition, there are various types of terminals such as notebook computers, mobile phones, and PDAs in WLAN. There is heterogeneity between these terminals. Also, different QoS (quality of service) is required for different applications of different terminals. Therefore, there is the above-mentioned problem when the multicast packet of the current IP layer is directly transmitted by WLAN. Because of these problems, it is very necessary to design a reliable multicast protocol in the MAC layer.

  In the prior art, a plurality of methods have already been proposed in order to realize highly reliable multicast transmission. For example, J. et al. Kuri and S.K. K. Text of “Reliable multicast in Multi-Access Wireless LANs” published by Kasera (see ACM / Kluwer Wireless Networks Journal, vol. 7, no. 4, pp. 359-369, August 1 K. S. Gupta, V.G. A text of “Reliable multicast MAC Protocol for Wireless LANs” published by Shankar (see ICC 2003, pp93-pp97, 2003); Tang and M.M. Text of “MAC Reliable Broadcast in AdHoc Networks” published by Gerla (see Proc. IEEE MILCOM 2001, pp. 1008-1013, Oct. 2001); T.A. Sum, L .; Hangang's “Reliable MAC layer multicast in IEEE 802.11 wireless networks” (see Proc. Of ICPP, pp. 527-536, Aug. 2002) and Hrishinsh Goss p. layer Multicast in IEEE 802.11 Based MANETs: Issues and Solutions "(see LCN '04, 2004).

  The methods submitted in the above-described prior art can be divided into the following two types. The first type is a negative feedback based (NCTS / NACK) mechanism, and the other type is a positive feedback based (CTS / ACK) mechanism. Usually, the efficiency of a multicast protocol based on negative feedback is high, but its reliability is poor. Commonly adopted methods include negative feedback-based multicast protocols such as LBP (Leader-based protocol), DBP (Delayed feedback-based protocol) and PBP (Probabilistic feedback-based protocol), and multicast with positive feedback. For example, BMW (Broadcast Media Window Protocol) and BMMM (Batch Processing Multicast Protocol) are included.

  LBP (representative base protocol) extends the RTS / CTS handshake mechanism and the error correction mechanism of response ACK under IEEE 802.11, thereby supporting multicast transmission with high reliability. In such a method, it is necessary to designate one leader among a group of recipients in advance. Before transmitting the multicast data packet, the source side (source) first transmits one multicast RTS packet (MRTS) to all group members. If the representative in the reception group is already ready for data reception, it responds with MCTS (multicast reception preparation completion packet), and in the opposite case, it does not respond. If other members in the receiving group are not ready to receive data, NCTS (negative CTS) is returned, and vice versa. In this handshake process, if a representative of a receiving group sends a CTS packet ready to receive, while a member is not ready to receive and responds with an NCTS packet, this NCTS packet It will collide with the CTS packet sent by the representative. When the source side senses the CTS packet, it recognizes that the channel has been successfully acquired and starts transmitting multicast data. After receiving the data packet, for the representative in the receiving group, if the data packet is received correctly, it responds with an ACK, otherwise it sends a NACK; for the other members of the receiving group, it succeeds. If received, it does not respond, otherwise it responds with NACK.

  Therefore, when the LBP method is applied to IEEE 802.11, it is difficult to determine how the receiving side should provide feedback. This problem exists in all negative feedback based protocols. In IEEE 802.11, when a collision or a link error occurs, the receiving side cannot receive the received packet correctly. Naturally, for example, a head of packet type, packet source address, destination address, etc. Information cannot be picked up. Therefore, it becomes difficult for the receiving side to determine whether or not to perform negative feedback and what kind of negative feedback to perform when the data packet cannot be correctly received. For example, it is difficult to determine whether to feed back NACK or NCTS. Extra work is needed to modify the IEEE 802.11 protocol to solve this problem.

  In addition, when the LBP method is applied to IEEE 802.11, the source side transmits multicast data, and then receives an error packet as a representative member of the non-receiving group, and then transmits a NACK packet. Collisions with ACK packets sent by the representative. Due to this collision, the source side cannot sense the ACK packet fed back by the representative in the receiving group, and retransmits the data packet. Therefore, the transmission side performs unnecessary retransmission. When an error occurs at a member where a data packet is transmitted, the member cannot obtain the serial number of the data packet, and therefore cannot determine whether the data packet is a retransmission data packet. Therefore, the member uniformly feeds back the NACK packet to the source side regardless of whether the data packet has been successfully received before. Therefore, the source side performs unnecessary retransmission.

  Further, when the LBP method is applied to IEEE 802.11, a capture effect is further generated. The capture effect means that when one node receives two packets at the same time, a data packet with strong reception power is captured correctly. In some circumstances, assume that the representative in the receiving group is very close to the access point (AP) and the other node is away from the AP. If the AP responds with a CTS and another node responds with an NCTS, this NCTS should collide with the CTS, but due to the capture effect, the CTS sent by the AP is correctly received on the source side and An NCTS response transmitted by a remote node cannot be received correctly. As a result, the source side erroneously determines that it can send data.

  The differences between the DBP method and the LBP method are as follows: 1) Channel reservation is performed only by CTS. 2) Avoid collision of multiple CTS with random timer.

  Hereinafter, the process of the DBP method will be described. First, the source side starts one time over timer (period is T), and then reserves a channel by transmitting MRTS (multicast transmission request packet). It is assumed that the timer period is T. After all MR members sense MRTS, they start one timer (the timer period can be selected randomly from {1, 2,..., L}). If the node A senses a CTS packet transmitted by another node before the timer time, the timer is canceled and the CTS packet is not transmitted. If node A cannot sense the CTS packet, it sends a CTS response when the timer expires. The source side waits for T time, and starts receiving data when receiving the CTS packet. The receiving members do not respond after receiving the data correctly. If there is an error in the received data, a NACK packet is transmitted to respond. The PBP and DBP methods are very similar, the only distinction being that the PBP method avoids CTS collisions with probability.

  Compared to the LBP method, the PBP and DBP methods require more time to reserve the channel. On the other hand, in order to select the optimal PBP response probability and DBP random timer period, it is necessary to know the size of this multicast group, but the size of the multicast group cannot be acquired at this stage. Therefore, it is necessary to acquire extra information in order to acquire parameters such as an optimal probability or a random timer period. This is also a drawback present in the PBP and DBP methods.

  In addition, as a method based on the positive feedback based on the prior art, a BMW (Broadcast Media Window Protocol) and a BMMM (Batch Processing Multicast Protocol) method are usually employed. Although these positive feedback-based methods overcome the drawbacks of the negative feedback methods described above, other problems are occurring. For example, the BMW method is less efficient because it simply considers one multicast process as multiple unicasts. In order to increase efficiency, a BMMM method was submitted. In the BMMM method, a new packet type (RAK: Billing Acknowledgment) was introduced to coordinate the ACK response of the receiving member. The RAK packet is set before the ACK packet, and instructs the receiving side member to transmit the ACK response in order.

FIG. 1 shows the basic process of the BMMM method. In the BMMM method, if a transmission side and n reception sides perform multicast communication, the transmission side starts transmitting data packets (DATA) after n RTS / CTS alternates in the previous period. After completing the DATA transmission, the sender transmits a RAK packet to each receiving side by polling. After receiving the RAK packet, the receiver sends an ACK response to the sender. The BMMM method is more reliable than the BMW method, but it is necessary to alternate n-to-RTS / CTS and n-to-RAK / ACK during transmission, and the overhead of the control packet (RTS, CTS, RAK and ACK) is very high large. Table 1 below shows the overhead of the physical layer control packet and the overhead of the data packet.

  In Table 1, the overhead of the physical layer control packet is compared with the overhead of the data packet, and the data packet to be transmitted here is 512 bytes. As can be seen from Table 1, the transmission data packet uses 15 time slots, but RTS, CTS and ACK use 120 time slots, and the resources of the transmission data packet do not reach 10% of the total resources.

  As can be seen from the previous discussion, while the previously submitted multicast method has solved the feedback collision problem and the control packet overhead problem to some extent, there are still other problems. For example, simply from the scope of application, these multicast transmission methods are all designed based on IEEE 802.11a / b / g and cannot be applied well to IEEE 802.11n. From the viewpoint of WLAN development, the emerging 802.11n standard has a transmission rate of up to 600 Mbps and is recognized as a next-generation wireless network technology. In order to increase WLAN throughput, IEEE 802.11n introduces some new features such as physical layer MIMO (multi-input multi-output), MAC layer data aggregation (ie network access point). (Sends multiple data packets at one time)) Optional speed arrangement reaching 576 types, etc. Some previously described multicast protocols do not take into account these new features and therefore cannot support higher speed multicast transmissions.

  Regarding the third problem (how to adjust the multicast transmission rate) to be solved by the reliable multicast method, some adaptive rate adjustment algorithms have already been submitted in the prior art. Compared to self-adaptive speed adjustment in unicast, self-adaptive speed adjustment in multicast has to solve the following two special problems. (1) How to acquire channel conditions by feedback from multiple members. In the case of unicast, the channel condition is usually determined based on the signal strength of the CTS packet transmitted by the receiving node. However, in the case of multicast, a collision occurs if a plurality of receiving nodes transmit CTS packets at the same time. (2) How to adjust the transmission rate according to many different channel conditions.

  For example, J. et al. A text of “RSM: a cross-layer autorate multi-function multi-rate wireless LANs” published by Villalo'n et al. (See IEEE Commun., 2007, referred to as reference SM in the following) Multicast) algorithm is proposed. The method backs a certain time before each node sends a CTS packet. This back time is determined by the node's own channel conditions. When the channel condition is good, the corresponding node back time is long, and when the channel condition is poor, the back time of the corresponding node is short. In this way, the node with the lowest channel condition preferentially uses the channel. When the AP receives the first CTS fed back, the AP adjusts the transmission speed according to the signal strength of the CTS.

  In the text of “Contention-Based Prioritized Opportunistic Medium Access Control in Wireless LANs” submitted by Miao Zhao et al. (See IEEE ICC, 2006, hereinafter referred to as Comparative Document 2), a kind of CTS detection is performed. This method is defined such that all receiving nodes transmit CTS packets at the same time, but the lengths of CTS packets transmitted by each node are different. If the channel condition is good, the length of the CTS packet to be transmitted may be increased, and if the channel condition is bad, the length of the CTS packet may be shortened. This causes a collision of multiple CTS packets at the AP, but after the collision, the longest CTS packet is still detected by the AP. By this method, it can be understood that the AP can detect the CTS packet transmitted by the node having the best channel condition. Thereafter, the AP adjusts the transmission rate according to the length of the CTS.

  Also, in the sentence of “Rate Adaptive Reliable Multicast MAC Protocol for WLANs” published by Anas Basalamah et al. (See IEEE VTC, 2006, hereinafter referred to as Comparative Document 3), a competition method based on priority is proposed. This method introduces a kind of Black Burst (BB) packet. Before all receiving nodes transmit CTS packets, they first transmit BB packets to occupy the channel. If the channel condition is good, the length of the BB packet may be increased, and if the channel condition is bad, the length of the BB packet may be shortened. After the receiving node transmits the BB packet, channel sensing starts. Since BBs are transmitted at the same time, collision occurs between BB packets. However, after a collision, the AP can still sense the longest BB packet. Thus, the receiving node with the best channel condition occupies the channel through the longest BB packet and successfully transmits the CTS packet. After receiving the CTS packet, the AP adjusts the transmission rate according to the signal strength.

  The above three methods work well when the number of ACM (Adaptive Coded Modulation) arrangements is relatively small. For example, in the method submitted by Miao Zhao et al., Four types of values are defined for the change in the length of the CTS, and each corresponds to four types of ACM arrangements of IEEE 802.11b. However, this method cannot work when there are many ACM arrangements supported by the standard. For example, IEEE 802.11n can support at most 576 speed arrangements, and correspondingly, if 576 kinds of CTS length changes are defined, a very large amount of resources are wasted. Analogously, the other two types of algorithms have this problem.

  In view of the above, the present invention requires a highly reliable MAC layer multicast transmission method, which can be applied to ACM placement. Chinese patent application No. 10 filed on November 19, 2007 by the same applicant of this application. 200710186021.7 submits some specific methods of the present invention, which are hereby incorporated by reference.

  The present invention provides a method for performing multicast transmission in a MAC layer of a wireless network, in which the receiving group members are grouped, only the representative node of each subgroup feeds back an MCTS packet to the transmitting side, and ACK information is sent to the MCTS packet. It is possible to improve the efficiency of the multicast protocol, reduce the overhead of the control packet, avoid the collision of multiple MRTS, and reduce the delay of multiple receiving nodes feeding back the MCTS to the transmitting node.

  The present invention further provides a method of grouping for multicast group members, and in a multicast transmission process performed in a wireless network, only one node in each subgroup is sent without sending feedback information to each multicast member. By feeding back the information, the delay of multiple nodes feeding back the CTS to the transmitting node was reduced.

  A method of performing multicast transmission at a media access control (MAC) layer in a wireless network, in which a transmission side divides multicast group members into subgroups according to channel conditions of the multicast group members and designates a representative node of each subgroup. And a step in which the transmission side multicasts a multicast transmission request packet indicating whether there is a data packet to be transmitted to the multicast group to a multicast group member and waits for a multicast reception preparation completion packet from each subgroup representative node; After receiving the multicast reception preparation completion packet from the representative node of each subgroup, the side maps at least one data packet to the multicast group member. And the number of data packets transmitted at the present time are recorded, and the representative node in each subgroup receives at least one data packet that has been multicasted. Recording a value indicating whether the transmitted data packet has been successfully received, not transmitting an acknowledgment packet (ACK), and transmitting a multicast reception preparation completion packet to the transmission side after a scheduled time period; Based on the value recorded in the bitmap field of the multicast reception ready packet from each representative node, it is determined whether there is a data packet loss. If there is a data packet loss, the lost data packet is sent when the next data packet is transmitted. , Send And a step of multicasting with the new data packet to.

  The present invention provides a reliable MAC layer multicast transmission method. The method employs an extensible implicit type confirmation (EIA) method. By using this method, transmission of ACK packets is eliminated through a method of loading confirmation information in MCTS packets. In addition, by canceling ACK packet transmission, avoiding the probability of ACK / NACK packet loss and collision, while the other protocol is installed by mounting the number of data packet indicating whether it was recently received successfully by MCTS Resolved a resend problem that doesn't need to exist.

  According to the present invention, multicast group members are divided into sub-groups, one representative node of each sub-group transmits feedback information to the transmission side, and each multicast group member returns feedback information to the transmission side. No need to send. Thus, the method of the present invention can reduce the delay of multiple receiving nodes feeding back the MCTS to the sender.

  In addition, the present invention provides a new characteristic and a plurality of transmission rate arrangements in the 802.11n MAC layer such as, for example, data aggregation, that is, a transmission side transmits a plurality of data packets to a receiving group member at a time. In view of this, a data set and adaptive rate adjustment algorithm adapted to multicast transmission are presented.

FIG. 3 shows a basic operation process of a prior art BMMM method. It is a figure which shows the RTS frame format in a prior art. FIG. 3 is a diagram illustrating an MRTS frame format for performing multicast transmission according to an embodiment of the present invention. FIG. 5 is a diagram illustrating an MRTS frame format during multicast transmission according to an embodiment of the present invention. FIG. 5 is a diagram illustrating an example of a bitmap (Bitmap) in the MCTS frame format illustrated in FIG. 4. It is a figure which shows the frame format of a multicast data packet. It is a figure which shows an example which performs a multicast in WLAN. It is a flowchart which acquires channel information using an Internet group management protocol packet. It is a figure which shows an example of the bitmap attached to the MCTS packet fed back of the representative node in the subgroup by this invention. FIG. 5 is a diagram illustrating a transmission process performed between an AP and a representative node of the receiving subgroup according to the present invention. It is a figure which shows the flowchart which performs the multicast transmission method by this invention Example. 6 is a performance improvement graph obtained by the method of the present invention compared to the prior art. 6 is a performance improvement graph obtained by the method of the present invention compared to the prior art. 6 is a performance improvement graph obtained by the method of the present invention compared to the prior art.

  Embodiments of the present invention will be described in detail below with reference to the drawings, and in the description, details and functions that are not necessary for the present invention are omitted to prevent the understanding of the present invention from being confused. ing.

  FIG. 2 is a diagram showing a frame format of RTS in the prior art in FIG. As shown in FIG. 2, a conventional RTS frame defined in 802.11 includes a frame control area, a duration area, a DA (destination address) area, and a TA (transmission side address) area. , And CRC (cyclic redundancy check). Among them, the frame control region is used to specify the frame type, the duration region is used for channel reservation, and the CRC region is used to determine whether the received frame is correct.

  FIG. 3 shows an MRTS frame format for multicast transmission in the MAC layer according to an embodiment of the present invention. As shown in FIG. 3, the only distinction between the MRTS frame format according to the present embodiment and the prior art RTS frame format shown in FIG. 2 is that the DA area indicating the destination address is changed to the RA area indicating the reception group address. That is. Such changes do not require changing the frame format. What should be specified is that this group address has been converted from an IP multicast address. In this field, it is known that the IP address is 32 bits and the MAC address is 48 bits. The IP group addresses are all D-type IP addresses, the high-order 4 bits are all 1110, and the remaining 28 bits may be used for mapping the multicast address of the MAC layer. As an illustration, consider 28 bits as a decimal number and convert it to a hexadecimal number, and the result is the required MAC address.

  FIG. 4 shows an MCTS frame format in multicast transmission according to an embodiment of the present invention. As shown in FIG. 4, the MCTS frame includes a frame control area, a duration area, a GA (group address) area, a TA (transmission side address) area, a bitmap (Bitmap) field, and a CRC. (Cyclic redundancy check) is included. Among them, GA (group address) is converted from the IP multicast address, and the method of generating the RA area in FIG. 3 is the same. The Bitmap field is added because the characteristics of the data set in IEEE 802.11n are taken into consideration. That is, when a node occupies a channel once, a plurality of data packets can be transmitted. Bitmap occupies 8 bits. When an error occurs in reception of a data packet, the corresponding bit in the Bitmap field is set to 0. Conversely, when the data packet is correctly received, the corresponding bit in the Bitmap field is set to 1. In the above embodiment, the AP can only transmit at most 8 data packets at a time. However, the present invention is not limited to this, and more or fewer data packets can be transmitted by setting different bits.

  FIG. 5 shows an example of a bitmap (Bitmap) field. For example, it is assumed that the network AP transmits five data packets Data (1), Data (2), Data (3), Data (4), and Data (5) at a time. If an error occurs when data packets Data (2) and Data (4) are received, the second bit and the fourth bit of Bitmap are set to “0” and the other bits are set to “1” as shown in FIG. Is fed back to the AP. After the AP receives the MCTS fed back by the receiving node, it can determine the accuracy status of the previously transmitted data packet by detecting each bit value in the Bitmap field.

  FIG. 6 illustrates the frame format of a multicast data packet according to the present invention. In addition to changing the original Address 4 (6 bits) defined in the standard in the area indicated by the deep color in FIG. 6 to three Station IDs (2 bits each), other data packets shown in FIG. The format is the same as defined in IEEE 802.11. The Station ID was assigned by the AP during the initial negotiation process between the node and the AP, and details of this process can be found in the IEEE 802.11 standard. That is, when one node and the network AP complete the initial negotiation process, the node is assigned one 2-bit Station ID. In IEEE 802.11, Address 4 This field is rarely used. The Address 4 field is used only when data is transmitted from the AP to the AP. Therefore, according to the present invention, the station ID of the representative node (sub-group leader) of each subgroup is notified using this idle field. FIG. 6 shows three fields of Station ID 1, Station ID 2, and Station ID.

  FIG. 7 shows an example of performing multicast in WLAN. As shown in FIG. 7, the source node in cell 1 transmits data to the multicast group in cell 2. The multicast data packet generated by the source node is finally transmitted to the multicast group G in the cell 2 via the access point AP1 in the cell 1 and the access point AP2 in the cell 2.

Here, the access point AP2 in the cell 2 performs transmission to the receiving group using the multicast method of the present invention. For ease of explanation, Table 2 below lists the meanings of some of the numerical values used in the explanation.

  When the MAC layer of the network AP2 in the cell 2 receives a multicast packet from the upper layer, the AP2 first translates the IP layer multicast address into the MAC layer address. Thereafter, the MRTS / MCTS handshake mechanism is activated to hold the channel. Before sending the MRTS, AP2 first determines whether there are any data packets in its output queue to be sent to the multicast group G. If there is, AP2 sets the subtype value of the frame control area in the MRTS packet to 0000 (the value is reserved in IEEE 802.11), indicating that there is a data packet to be transmitted to multicast group G. Conversely, when there is no data packet to be transmitted to the multicast group G, the AP 2 sets the subtype value of the frame control area in the MRTS packet to 0001 (this value is reserved in IEEE 802.11), and the multicast group G Indicates that there is no data packet to be transmitted. Through the collision avoidance process, AP2 starts multicasting MRTS when the channel is idle.

  After receiving the MRTS packet from AP2, each group member records the Subtype value in the MRTS, responds to the received MRTS packet, and feeds back the MCTS packet to the AP. Since there are a plurality of members in the plurality of groups G, when each member responds to the MRTS packet transmitted by AP2 and feeds back the MCTS packet, AP2 receives the plurality of collided MCTS packets. In order to avoid these packet collisions and at the same time reduce the overhead and delay of the control packet, according to an embodiment of the present invention, one large multicast group is divided into several sub-groups. After grouping a large multicast group, it is not necessary for each node to feed back MCTS packets to AP2, and one leader among group members of each subgroup may feed back MCTS packets to AP2 in order.

  Hereafter, how to perform grouping for a large multicast group, how to select a representative node in the grouped subgroup, and how to notify each node which node is the representative node explain.

  The purpose of grouping multi-group group members is to divide nodes with close channel conditions into one subgroup. If one member in the group successfully receives a data packet, the other members of the same subgroup may be considered successfully received the data packet. Based on this assumption, it is not necessary for all nodes in the subgroup to feed back MCTS information to AP2. In order to divide nodes with close channel conditions into one subgroup, it is necessary to know channel conditions between AP2 and a plurality of receiving nodes. According to the present embodiment, as an example, an Internet Group Management Protocol (IGMP) packet is adopted to acquire a channel condition. IGMP is a group management protocol. When multicast is to be supported on the Internet, it is necessary to first support the IGMP protocol.

  FIG. 8 shows a flowchart for acquiring channel information using an Internet group management protocol packet. As shown in FIG. 8, when a node intends to join a multicast group, first, in step S801, the node in the network sends multicast group join information (IGMP host Membership report: IGMP host member report) to a router to which the node is connected. ) To register with the AP or router. After the node successfully joins the multicast group, in step S802, the router sends query (IGMP host Membership Query) information to the node that joined every second, so that the joined node enters the group. Check if it exists. After receiving the query information, in step S803, the node needs to transmit response information (IGMP host Membership response) to the AP or router. Finally, in step S804, if the joined node wishes to leave the multicast group, it sends away information (Leave message) to the AP or router.

  As can be seen through the above process, when a node initially joins a multicast group and every second thereafter, the node sends IGMP information to the AP or router. By observing IGMP information through the AP, after the AP receives an IGMP packet from each group member, the AP can measure the received signal strength (RSS) from each group member. Thereafter, the AP groups these nodes according to the RSS values of the received nodes. Due to limitations of the multicast data packet format, the number of subgroups that can currently be supported is three. It should be noted that the number of subgroups supported by the present invention is not limited to three, and a larger number of subgroups can be supported by changing the format of the multicast data packet according to the concept of the present invention. . After grouping each group member accessing the network, one node is selected from each subgroup as a representative. As an example, a representative of each subgroup can be selected using a polling scheme. That is, the group members of each subgroup are made representative nodes of this subgroup in order, and thus each node has an opportunity to become a representative node. It should be noted that the present invention is not limited to this, and other methods may be adopted to select the representative node of each subgroup. For example, the node having the weakest signal strength in the subgroup is selected. As a representative, after the AP receives the MCTS information fed back from the representative of the subgroup, it can be ensured that each node of the subgroup successfully receives the data packet.

  After selecting the representative node of each subgroup, it is necessary to notify the representative of this subgroup that a node among the group members in the subgroup has been selected. As can be seen from the above description of the multicast data packet format, there are three Station ID fields in the multicast data packet (Multicast Data). The AP can enter the ID information of the representative node of each subgroup in these three fields. When a multicast member receives a data packet, it first checks whether the Station ID field carried in the data packet is the same as its own ID. If they are the same, it can be seen that the multicast member has been selected as the representative of the subgroup to which he belongs. Therefore, the node needs to feed back the MCTS packet to the AP. In order for the representative node to sequentially transmit MCTS information to the AP and avoid collision between MCTS packets, the priority of feeding back the MCTS packet of each representative node is associated with the position in the multicast data packet of that ID. You only have to set it. For example, if the ID of a representative node is placed in the second place in the Station ID field, after the node receives the MRTS packet, it must not feed back the CTS packet immediately, wait for TMCTS, and then send the MCTS packet. Means to send. That is, the AP enters the position of the node ID of the representative node of each subgroup in the node ID field of the data packet, and indicates the priority of the representative node. If the multicast member is checked and the three Station IDs in the DATA packet differ from their own IDs, the node is silent and does not send any feedback information.

  AP2 starts to transmit multicast data after successfully receiving the feedback MCTS packets of the representative nodes of all subgroups. Thereafter, all multicast group members receive the multicast data. The multicast group member determines whether it is necessary to respond with an ACK according to the subtype value previously recorded in the frame control area in the MRTS packet. Only when the Subtype value is 0001 and indicates that there is no data of the multicast group to be transmitted to the AP, the group member responds with an ACK to the AP. Conversely, if the subtype value is 0000 and indicates that the AP still has data to send to the multicast group, in such a situation, the group member does not respond to the AP with an ACK, and the data packet It only needs to record whether it was successfully received.

  Suppose that there are a plurality of data packets to be transmitted to the multicast group G to the AP 2. In this case, the AP sets the subtype field in the MRTS packet to 0000. When the receiving group member detects the setting, it is understood that it is not necessary to respond with an ACK.

  After one session process (MRTS / MCTS / DATA), AP2 does not know whether the transmitted data packet has been successfully received by all nodes. Subsequently, AP2 activates the MRTS handshake process for the next data packet to suspend the channel. After receiving this MRTS packet, the representative node of the subgroup returns the reception status of a plurality of data packets transmitted at one time of the AP recorded before that to the AP in the Bitmap field (details about the Bitmap field) of the MCTS packet. This description is added to the Bitmap setting example shown in FIG. Thereafter, the subgroup representative node transmits an MCTS packet to AP2. AP2 receives the MCTS packet transmitted from all the subgroup representative nodes, and then performs a “bit AND” operation on each bit value in the Bitmap field attached to the MCTS packet to obtain one confirmation indicator confirm_flag value. To get. Based on the obtained confirm_flag value, the AP determines how to retransmit the data packet that could not be successfully received.

  Hereinafter, how the AP determines a data packet that has not been successfully received by a multicast group member will be described with reference to FIG. FIG. 9 is a diagram showing an embodiment of a bitmap attached to an MCTS packet fed back from a representative node in a subgroup according to the present invention. Temporarily, AP2 sends eight data packets Data (1), Data (2), Data (3), Data (4), Data (5), Data (6), Data (7) to a multicast group member at a time. And Data (8) are transmitted. As shown in FIG. 9, the following bitmap (Bitmap) information is attached to the MCTS packet fed back to AP2 by the representative nodes of the three subgroups. Assuming that the representative node 1 of the subgroup 1 successfully receives the data packet Data (1), Data (3), Data (5), Data (6), Data (7) and Data (8), and the data packet It is assumed that Data (2) and Data (4) have not been successfully received. In this case, the representative node 1 sets the first, third, fifth, sixth, seventh and eighth bits of the bitmap field in the MCTS packet to “1”, and the data packet Data (1), Data ( 3) Indicates that Data (5), Data (6), Data (7) and Data (8) have been received. In addition, the representative node 1 sets the second and fourth bits of the bitmap field in the MCTS packet to “0” and indicates that the data packets Data (2) and Data (4) have not been successfully received. Show. Similarly, the representative node 2 of the subgroup 2 has successfully received the data packet Data (1), Data (2), Data (5), Data (6), Data (7), and Data (8), and the data. Packets Data (3) and Data (4) could not be received successfully. Therefore, the representative node 2 sets the first, second, fifth, sixth, seventh and eighth bits of the bitmap field in the MCTS packet to “1”, and Data (1), Data (2), Data ( 5), Data (6), Data (7) and Data (8) are successfully received, and the representative node 2 sets the third and fourth bits of the bitmap field in the MCTS packet to “ It is set to “0” to indicate that the data packets Data (3) and Data (4) could not be received successfully. Similar to this, the representative node 3 of the subgroup 3 has successfully received the data packet Data (1), Data (3), Data (5), Data (6) and Data (8), and the data packet Data ( 2) Data (4) and Data (7) could not be received successfully. Therefore, the representative node 3 sets the first, third, fifth, sixth and eighth bits of the bitmap field in the MCTS packet to “1”, and the data packet Data (1), Data (3), Data ( 5) Indicates that Data (6) and Data (8) have been successfully received. Further, the representative node 3 sets the second, fourth and seventh bits of the bitmap field in the MCTS packet to “0”, and succeeds in the data packet Data (2), Data (4) and Data (7). Indicates that it could not be received. Thereafter, the AP performs a “logical product” operation on the bits corresponding to the bitmap field in the MCTS packet fed back by the representative nodes 1 to 3 to obtain the confirmation indicator confirm_flag value. As shown by the value corresponding to confirm_flag in FIG. 9, by performing “logical product” on the bit corresponding to the bitmap field fed back by each representative node, the first, fifth, sixth and eighth The bit is “1”, and the second, third, fourth and seventh bits are “0”. Therefore, the AP confirms that an error has occurred in the transmission of the data packets Data (2), Data (3), Data (4), and Data (7), and these data packets Data (2) and Data (3). , Data (4) and Data (7) are retransmitted.

  Hereinafter, a transmission process performed between an AP and a group member according to an embodiment of the present invention will be described with reference to FIG. As shown in FIG. 10, it is assumed that the multicast group has one transmission side (AP) and three reception subgroups. First, the AP performs grouping for the multicast group based on IGMP information, and designates the representative node of each subgroup. When the transmitting side (AP) transmits data, it usually tries to transmit a plurality of data packets to the outside. As described above, the transmission side can transmit a plurality of data packets at a time based on the collective characteristics of the data packets. Before transmitting the data packet for the first time, the transmitting side first transmits the MRTS in the first session, and the representative nodes (GH1 to GH3) in the receiving subgroup transmit the MCTS to perform the alternate operation. FIG. 10 shows that the representative node of the reception subgroup transmits the MCTS packet according to the priority order to avoid the collision of the MCTS packet. After the MRTS / MCT alternation ends, the transmitting side starts the first data packet transmission (the shadow line packet in FIG. 10). So far, the first session process is over.

  In other protocols, in order to ensure reliable transmission, the receiving side transmits an ACK packet after receiving the transmitted data packet to confirm that the transmitted packet has been received. Unlike other protocols, in the present invention, before the data packet transmission is completed, that is, when the subtype field of the frame control area in the MRTS packet is 0000, the representative node of the receiving subgroup The ACK packet sent was removed. Thereafter, in the second session process, in order to transmit the second data packet, the MRTS / MCTS alternate is similarly performed between the transmitting side and the representative node of the receiving subgroup to execute initialization. After the transmitting side transmits the MRTS packet in the second session process, the representative node of the receiving subgroup needs to feed back the MCTS packet. As described above, the MCTS fed back at this time has already been changed, and includes a Bitmap field indicating the number of the latest data packet that has been successfully received once recently. If a plurality of data packets sent by the sender at the first time are correctly received by the representative nodes of all the receiving subgroups, and each representative in the Bitmap field of the MCTS packet fed back by the representative of each receiving subgroup in the second session process Assume that the value of the bit corresponding to the data packet number is set to “1”. When the transmitting side finds that the bit values corresponding to the data packet numbers in the Bitmap field in the MCTS packet fed back from the representative nodes of all the receiving subgroups are all “1”, all the receiving sides are transmitted at the first time. It is determined that all data packets have been received correctly, and transmission of the second transmission data can be started. It should be noted that after the transmission side transmits a data packet for the first time, a new representative node may be indicated by a rule such as polling. Of course, the original designated node may still be used.

  After transmitting the second plurality of data packets, the transmitting side prepares the third data packet transmission in the third session process. Similarly, before transmitting the third data packet, MRTS / MCTS alternate is performed between the transmission side and the reception side. There is a possibility that the data packet transmitted for the second time may be lost at a certain representative node during transmission. After the transmission side finishes the MRTS packet transmission, the representative node of the receiving subgroup feeds back the MCTS packet. At this time, since some representative nodes may lose some data packets in the data packet transmitted the second time, the bit corresponding to the lost data packet number in the Bitmap field of the fed back MCTS packet. The value of may be set to “0” due to the loss of the data packet, and corresponds to the Bitmap field of the MCTS packet fed back by the representative node of the receiving subgroup that has successfully received the data packet transmitted the second time. The bit value to be performed is “1”. If the corresponding indicator obtained after performing a "logical AND" operation on the bit corresponding to the MCTS packet fed back by the receiving side is 0, the transmitting side sent the second time when the receiving side lost Data packets can be determined. In this case, in the third session process, the transmission side first transmits the lost data packet in the second transmission, and then transmits the data packet to be transmitted in the third time. Therefore, the analogy is made as described above until all data packets are transmitted in the fourth session process.

  According to the present invention, the MCTS packet that responds to the next data packet is used to check whether the receiving side has correctly received the previously transmitted data packet, thereby eliminating the overhead of the ACK packet. In addition, the group members on the receiving side are grouped according to factors such as the strength of the received signal, and only the representative node of such a subgroup feeds back the MCTS packet, thereby delaying the multiple TSs to feed back the MCTS to the transmitting node. Can be reduced. Also, some alternate overhead is eliminated by transmitting a new data packet to be transmitted and a previously transmitted data packet in one session process.

Hereinafter, a transmission process performed between an AP and a representative node of a subgroup according to the present invention will be described with reference to FIG. First, in step S1101, the transmission side (AP) is activated, and the AP groups the multicast group according to the IGMP information, and designates the representative node of each subgroup. Then, the AP broadcasts the MRTS packet to the wireless network. In step S1102, the transmission side starts the sender's timer, sets the timer period to T ₁ = T _MCTS + SIFS (the specific meaning of each parameter is listed in Table 2), and the MCTS that the reception side feeds back. Wait for. After the receiving side receives the MRTS packet, in step S1103, the representative node of each subgroup calculates the time to wait before responding to the MCTS according to its priority. The calculation of the waiting time of each representative node is as follows. T ₂ = m × SIFS + (m−1) × T _MCTS (where m is the priority of each representative node). Each representative node sets its timer period to T according to the waiting time calculated by itself. Thereafter, in step S1104, each representative node mounts a value indicating whether or not the data packet transmitted this time has been successfully received in bits corresponding to the plurality of data packet numbers received in the Bitmap field of the MCTS packet. If such a data packet is not successfully received, the corresponding bit is set to zero. If such a data packet is successfully received, the corresponding bit is set to 1 (as described above). The timer of the representative node reaches time, that is, after ₂ hours T, the MCTS packet is transmitted to the transmitting side.

Next, in step S1105, the transmitting side, before the period T ₁ of the own timer, determines whether it has received the MCTS packet from the receiving side. In step S1105, it is determined that it has not received the MCTS packet before the period _{T 1,} the transmitting side is returned to step S1101. When the MCTS packet fed back before the period T ₁ is received, the process proceeds to step S 1106, the current timer is canceled, the value of each corresponding bit is picked up from the Bitmap field of the received MCTS packet, and the value of each bit Record. Thereafter, in step S1107, the transmitting side determines whether or not the MCTS packet fed back by all the representative nodes has been received. If it is determined in step S1107 that all representative nodes have not received the feedback MCTS packet, the process returns to step S1102 to wait for another MCTS packet. If it is determined in step S1107 that all representative nodes have received the feedback MCTS packet, the process advances to step S1108. In step S1108, the transmission side performs a “logical product” operation on the corresponding bit distribution in the bitmap field of the MCTS packet fed back to each representative node, and obtains a confirmation indicator confirm_flag value. After that, in step S1109, it is determined whether the value of each bit corresponding to all the acquired confirm_flag is “0” or “1”. When the value corresponding to the acquired bit is “1”, the representative node has successfully received the data packet corresponding to the plurality of data packet values transmitted at the previous time on the transmission side, and the value corresponding to the acquired bit is “ In the case of “0”, the representative node indicates that the data packet corresponding to the plurality of data packet values transmitted by the transmitting side last time has not been successfully received.

Next, when the determination result of step S1109 is negative, the flow proceeds to step S1110, and the transmission side can successfully receive a plurality of data packets to be transmitted this time depending on the number of data packets that could not be received successfully. The missing data packet is added, and the new data packet corresponding to the number of data packets to be retransmitted is removed. If the determination result in step S1109 is affirmative, the representative node asserts that all data packets transmitted this time have been successfully received. In this case, the process proceeds to step S1111 and the transmitting side transmits a new data packet to the receiver. After steps S1110 and S1111, in step S1112, the transmission side sequentially transmits a plurality of data packets (which may include retransmission data packets) to be transmitted to the receiver. Thereafter, in step S1113, the representative node of the reception subgroup detects whether there is a data packet that could not be successfully received. If such a data packet is not successfully received, the corresponding bit is set to zero. If such a data packet is successfully received, the corresponding bit is set to 1 (as described above) to construct the MCTS packet. Step S1113 may be arranged after the step S1104, and transmits when it is the time of the timer of the representative node, i.e. _{T 2} hours later, the MCTS packet to the transmitting side.

  In the above description of the prior art, the multicast self-adaptive speed adjustment algorithm (refer to the above-mentioned comparative documents 1 to 3) in the prior art WLAN has already been described. Two problems must be solved for the self-adaptive speed adjustment of multicast. (1) How to solve the multiple feedback information collision problem (2) How to adjust the transmission rate according to the channel conditions of multiple receiving nodes. For the problem (1), the MCTS packet is fed back in order by the method submitted by the present invention, so that the feedback information collision problem is easily solved. For the above problem (2), the transmission rate is adjusted by the receiving node which is the worst in both comparative documents 1 and 2, and although this method can increase the reliability, it reduces the system efficiency. The method submitted in Comparative Document 3 adjusts the speed according to the best receiving node, and such an adjustment method is an extreme idea. According to the method submitted by Comparative Document 3, a better system throughput can be obtained, but the reliability of the user cannot be guaranteed. In order to satisfy the two requirements of data packet reception reliability and system throughput, the present invention proposes a new self-adaptive rate adjustment algorithm, which not only satisfies a certain degree of reliability, but also at the same time the system average throughput. Maximization can be realized.

According to the present invention, the self-adaptive speed adjustment is regarded as an optimization problem with one limitation, and the optimization function is represented by the following formula (1).

The limiting condition is defined by the following formula (2).

sub PDR> P _thr (2)

Here, Thr _ave indicates the average throughput of the multicast member, R indicates the transmission speed in a constant ACM modulation method, and BER is obtained by adopting the ACM method specified in the situation of a constant signal-to-noise ratio. SNR is the signal-to-noise ratio of the channel, N is the number of multicast members, and PDR (Packet Delivery Ratio) is the rate at which data packets are successfully received. Assuming that BPSK modulation is employed in IEEE 802.11, R = 1 Mbps. In the above formula, the parameter PDR indicating the rate at which the data packets are successfully received is one reliability index, and is specifically defined by the following formula (3).

  Here, PLR (Packet Loss Rate) indicates the packet loss probability of the data packet, and BER (Bit Error Rate) indicates the bit error probability in the data packet.

  As can be seen from the above description, the optimization goal of this algorithm is to maximize the average throughput, and the limiting condition is to satisfy a certain packet success rate.

  12 to 14 are graphs of performance improvement obtained by the method of the present invention compared to the prior art.

  The present invention implements EIA, LBP, DBP, BMW and IEEE 802.11 algorithms using OPNET 11.5. The following indicators are used to measure the performance of the method of the present invention.

(1) Ratio of successfully received data packets (PDR): number of successfully received data packets / number of data packets to be received (2) Average packet delay: This delay is the MAC layer of the data packet AP It is calculated from the time of entering the queue until it is successfully received by the multicast group group member.

(3) Delay jitter In comparison with the method of the present invention, the parameters listed in Table 3 below are employed.

  FIG. 12 shows a curve in which the PDR changes depending on the number of multicast group members. As can be seen from FIG. 12, the EIA has obtained the best PDR. There are two main reasons for this: (1) With the sequential feedback of group members, the AP can obtain information on each subgroup. However, for other protocols based on negative feedback, the AP cannot obtain information on all subgroup members due to collision, time over, etc. (2) Confirmation information is mounted on the MCTS, and ACK packet loss and retransmission due to collision are reduced.

  FIG. 13 shows a graph in which the delay varies depending on the number of multicast group members. This figure compares trends that change depending on the number of group members of the delayed multicast. Since IEEE 802.11 does not have any handshaking mechanism and retransmission mechanism, the delay is the smallest. The EIA delay is larger than the IEEE 802.11 delay and smaller than the other algorithm delays.

  FIG. 14 shows a comparison diagram of delay jitter. As shown in FIG. 14, different delay jitters brought by a plurality of protocols are compared. As can be seen from FIG. 14, the delay jitter of EIA is the smallest. For LBP and DBP, a multicast group member needs to respond with two control packets (CTS / NCTS sum ACK / NACK) in one session. When responding with an ACK / NACK, there is a possibility of loss or collision, causing the next unnecessary transmission. However, the present invention does not have this problem.

  So far, preferred embodiments of the present invention have been described. It should be understood by those skilled in the art that various modifications, replacements and additions can be made without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should not be understood as being limited to the specific embodiments described above, but is limited only by the scope of the appended claims.

Claims (20)

A method of performing multicast transmission at a media access control (MAC) layer in a wireless network,
The transmitter divides the multicast group members into subgroups according to the channel conditions of the multicast group members, and indicates the representative node of each subgroup;
A step of multicasting a multicast transmission request packet indicating whether there is a data packet to be transmitted to a multicast group to a multicast group member, and waiting for a multicast reception preparation completion packet from each subgroup representative node;
After the transmission side receives the multicast reception preparation completion packet from the representative node of each subgroup, multicasts at least one data packet to the multicast group member, and records the number of the data packet transmitted at the present time;
After the representative node in each subgroup has received at least one multicast data packet, record a value indicating whether or not the data packet transmitted this time has been successfully received in the bitmap field of its own multicast reception ready packet. Transmitting a multicast reception preparation completion packet to the transmission side after a scheduled time period without transmitting an acknowledgment packet (ACK);
The sending side judges whether there was a data packet loss based on the value recorded in the bitmap field of the multicast reception ready packet from each representative node. If there was a data packet loss, it was lost the next time the data packet was sent Multicasting a data packet with a new data packet to be transmitted. The method according to claim 1, further comprising the step of the sender side first translating the multicast address of the IP layer into the group address of the media access control layer before transmitting the multicast transmission request packet. The method according to claim 1, wherein the transmitting side divides multicast group members having close channel conditions into one subgroup. The method according to claim 3, wherein the sender groups the multicast group members by measuring the signal strength from each multicast group member. The method according to claim 1, wherein the transmitting side indicates a representative node of each subgroup by setting a node ID in a multicast data packet. The method according to claim 5, wherein the transmitting side puts a node ID position of each subgroup representative node in a node ID field of a data packet to indicate a priority of the representative node. The method of claim 6, wherein the multicast data packet includes a three node ID field. The method of claim 1, wherein the multicast group members are divided into at most three subgroups. The bit map field of the reception preparation completion packet includes a plurality of bits each indicating whether the representative node has correctly received the at least one data packet transmitted to the transmission side at a time. Item 2. The method according to Item 1. If the representative node fails to successfully receive one or more data packets, the representative node sets the bit corresponding to the number of data packets that could not be successfully received in the bitmap field to “0”. The method of claim 9, further comprising the step of setting. When the representative node has successfully received the data packet, the representative node further includes a step of setting a bit corresponding to the number of the data packet successfully received in the bitmap field to “1”. The method of claim 9. The transmitting side performs a “logical product” operation on the corresponding bits included in the bitmap field of the reception ready packet that each representative node has fed back to the transmitting side, so that the multicast group member succeeds. The method according to claim 10 or 11, further comprising the step of establishing a confirmation indicator of a data packet that could not be received and retransmitting the data packet that could not be successfully received by the multicast group member. The value of the bit obtained through the "logical product" operation is 0, and the transmission side determines that the data packet corresponding to the bit of the number has not been successfully received. Method. The method according to claim 12, wherein if the value of the bit obtained through the "logical product" operation is 1, the transmitting side determines that the data packet corresponding to the bit of the number has been successfully received. . The method according to claim 1, wherein the transmitting side indicates whether there is a data packet to be transmitted to a multicast group member by a frame control region subtype field in the multicast transmission request packet. The method according to claim 15, wherein the transmitting side sets a subtype field to 0001 when there is no data packet to be transmitted to a multicast group member on the transmitting side. The method according to claim 15, wherein if there is a data packet to be transmitted to a multicast group member on the transmitting side, the transmitting side sets a subtype field to 0000. Each representative node further includes a step of calculating a time period to wait before sending a multicast reception ready packet response according to its own priority, and sequentially transmitting a multicast reception ready packet to the transmission side. The method of claim 1, wherein: The representative node further includes a step of feeding back an acknowledgment packet to the transmission side after receiving the last transmitted data packet when the transmission side indicates that there is no data packet to be transmitted. The method according to 1. The sender performs self-adaptive speed adjustment for multicast speed according to the following formula:

The limiting condition is sub PDR> P _thr .
Here, Thr _ave indicates the average throughput of the multicast members, R indicates the transmission speed in a constant ACM modulation scheme, and BER is a bit obtained by adopting a specific ACM scheme in a constant signal-to-noise ratio situation. Indicates the error rate, SNR indicates the signal-to-noise ratio of the channel, N indicates the number of multicast members, PDR (Packet Delivery Ratio) indicates the rate at which data packets are successfully received, and is expressed by the following equation The method according to claim 1.

Images