WO2008020731A1 - Procédure multidestination dans un réseau radio - Google Patents

Procédure multidestination dans un réseau radio Download PDF

Info

Publication number
WO2008020731A1
WO2008020731A1 PCT/KR2007/003946 KR2007003946W WO2008020731A1 WO 2008020731 A1 WO2008020731 A1 WO 2008020731A1 KR 2007003946 W KR2007003946 W KR 2007003946W WO 2008020731 A1 WO2008020731 A1 WO 2008020731A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
station
frame
originator
block ack
Prior art date
Application number
PCT/KR2007/003946
Other languages
English (en)
Inventor
Ji Young Huh
Jin Ho Son
Sook Hyun Yang
Vladimir M. Vishnevsky
Andrey I. Lyakhov
Mikhail Y. Yakimov
Alexander A. Safonov
Original Assignee
Lg Electronics Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR1020070018329A external-priority patent/KR20080016420A/ko
Application filed by Lg Electronics Inc. filed Critical Lg Electronics Inc.
Publication of WO2008020731A1 publication Critical patent/WO2008020731A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1868—Measures taken after transmission, e.g. acknowledgments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/189—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast in combination with wireless systems

Definitions

  • the present invention relates to wireless communication, and more particularly, to a multicast procedure in a wireless network.
  • message transmission types may be classified into unicast, multicast, and broadcast according to the number of target devices or destination devices.
  • Unicast is a message transmission type in which a destination device for transmitting a message consists of one terminal.
  • Both multicast and broadcast are a message transmission type in which the destination device for transmitting the message consists of a plurality of terminals.
  • a target address or a destination address field of a transmission frame is set as a multicast group address.
  • Broadcast is special multicast in which the multicast group address identifies all terminals. Therefore, hereinafter, the term 'multicast' is intended to include the term 'broadcast', unless not permitted by nature.
  • multicast a single data stream is simultaneously transmitted to a plurality of destination terminals, and thus data traffic can be reduced, and a channel can be effectively used.
  • Such multicast may be useful in the provision of various applications, for example, video conference, corporate communication, distance learning, software distribution, stock quotes, news, and so on.
  • multicast can be used in a game which is played by multi-users over a wireless home network or be used in an application that shares streaming data.
  • the multicast is based on a concept of a recipient terminal group (i.e., multicast group) interested in a specific data stream.
  • a recipient terminal group i.e., multicast group
  • terminals interested in the reception of the multicast data have to be registered to a multicast group.
  • the multicast group is identified by a multicast MAC address.
  • MAC Medium Access Control
  • a higher layer than the MAC layer is responsible for generation, registration, deregistration, and modification of the multicast group. Since such issues (e.g., generation, registration, etc.) of the multicast group are identified by the MAC address, descriptions thereof will not be discussed herein.
  • the present invention provides a multicast procedure in which a multicast service can be provided through a wireless network in a further reliable and effective manner.
  • a multicast method in a wireless network comprising the steps of: transmitting, by a first station, a plurality of data frames in which a destination address field is set to an address of a specific multicast group; and performing a block acknowledgment (ACK) procedure between one or more second stations registered to the multicast group and the first station.
  • ACK block acknowledgment
  • the step of performing a block ACK procedure may comprise: transmitting, by the first station, a block ACK request frame to the second station; and transmitting, by the second station, a block ACK response frame which indicates whether the plurality of data frames are successfully received in response to the block ACK request frame.
  • the block ACK procedure may be performed by unicast, and the block ACK procedure may be performed with respect to all stations registered to the multicast group or is performed with respect to only one or more stations.
  • the multicast method may further comprise, prior to the step of transmitting a plurality of data frames, ensuring a channel between one or more third stations registered to the multicast group and the first station.
  • the ensuring of a channel may comprise exchanging a Request To Send (RTS) frame and a Clear To Send (CTS) between the first station and the third station.
  • RTS Request To Send
  • CTS Clear To Send
  • members of the multicast group may do not have neighboring stations hidden from the first station, and the third station may be any one of stations selected from the members of the multicast group.
  • the members of the multicast group may have one or more fourth stations having neighboring stations hidden from the first station, and the third station may include all of the fourth stations.
  • a multicast method in a wireless network comprising the steps of: transmitting, by a first station, a first multicast block ACK setup request frame in which a destination address field is set to an address of a specific multicast group; and transmitting, by a second station which belongs to members of the multicast group and intends to use a block ACK mechanism in a multicast service, a multicast block ACK response frame to the first station in response to the first multicast block ACK setup request frame.
  • the multicast method may further comprise: transmitting, by the first station, a plurality of data frames in which a destination address field is set to an address of a multicast block ACK group including the second station; and transmitting, by the second station, a block ACK frame after the plurality of data frames are all received.
  • the multicast block ACK response frame may include information on a maximal buffer size that can be used by the second station and may further comprise: determining a maximal burst size of data that is multicast in a subsequent step by using information on the maximal buffer size by the first station receiving the multicast block ACK response frame; and transmitting, by the first station, a second multicast block ACK setup request frame which includes the maximal burst size and in which a destination address field is set to an address of a specific multicast group.
  • the multicast procedure may further comprise: multicasting, by the first station, a data frame having a data size less than or equal to the maximal burst size; and transmitting, by the second station, a block ACK frame to the first station.
  • a multicast method in a wireless network comprising: selecting one or more recipient stations from members of a multicast group by an originator station that intends to transmit multicast data; performing a channel ensuring procedure by using unicast traffic between the originator station and the selected recipient station; transmitting, by the originator station, the multicast data in which a destination address field is set to an address of the multicast group; and performing a block ACK procedure on the transmitted multicast data between the originator station and the selected recipient station.
  • all of the members of the multicast group may do not have neighboring stations hidden from the originator station, and the selected recipient station may be any one of stations belonging to the members of the multicast group.
  • one or more stations selected from the members of the multicast group may have neighboring stations hidden from the originator station, and the selected recipient station may include the one or more stations.
  • a multicast service can be provided through a wireless network in a further effective and reliable manner.
  • FIG. 1 illustrates an example of a conventional management frame format
  • FIG. 2 illustrates a frame control field of Fig. 1 ;
  • FIG. 3 is a message flow diagram illustrating a procedure for generating a multicast block ACK group and for transmitting multicast data by using the generated multicast block ACK group according to an embodiment of the present invention
  • Fig. 4 is a message flow diagram illustrating an RTS-I procedure according to an embodiment of the present invention
  • Fig. 5 is a message flow diagram illustrating a Block ACK (B-ACK) procedure according to an embodiment of the present invention
  • Fig. 6 is a view for explaining a multicast transmission procedure according to an embodiment of the present invention, when there is no recipient having a neighboring station hidden from an originator; [25] Fig.
  • FIG. 7 is a message flow diagram illustrating an indirect multicast procedure according to an embodiment of the present invention
  • Fig. 8 is a message flow diagram illustrating an indirect multicast procedure modified according to another embodiment of the present invention
  • Fig. 9 is a view for explaining an RTS-CTS exchange procedure, a multicast data transmission procedure, and an ACK procedure, each of which is performed for reliable multicast data transmission when there is a recipient having a neighboring station hidden from an originator;.
  • FIG. 10 illustrates a simulation scenario in a hot spot
  • FIG. 11 illustrates a simulation scenario in a narrow ring
  • Fig. 12 and Fig. 13 are graphs showing simulation results related to a throughput with respect to an average transmission time in a hot spot scenario
  • Fig. 14 and Fig. 15 are graphs showing simulation results related to an average percent of packet losses and a maximal percent of packet losses in a hot spot scenario
  • Fig. 16 and Fig. 17 show simulation results related to a throughput and an average transmission time in a ring scenario
  • Fig. 18 and Fig. 19 show simulation results related to an average percent of packet losses and a maximal percent of packet losses in a ring scenario. Best Mode for Carrying Out the Invention
  • a terminal that has received a multicast frame transmits to an originator of the multicast frame an acknowledgement (ACK) frame for the received multicast frame.
  • ACK is collectively carried out for a plurality of multicast frames rather than individually carried out for each multicast frame received.
  • a method for collective ACK may use a block ACK scheme. The collective ACK may not only increase reliability in the transmission of a multicast frame but also decrease overhead that occurs when a plurality of ACK frames are transmitted.
  • a data burst size for collectively transmitting ACK messages (i.e., a size of a multicast data stream received prior to the transmission of a block ACK frame) is informed to a destination terminal in advance.
  • the data size is determined according to a size of buffer included in the destination terminal. This will be described in detail hereinafter.
  • the block ACK method of the multicast service may be determined in such a way that the originator transmits to the recipient a multicast block ACK setup request (e.g., Multicast (Mcst) ADD Block ACK (ADDBA) request) message, and the recipient transmits to the originator a multicast block ACK setup response (e.g., Mcst ADDBA response) message in response to the multicast block ACK setup request message.
  • a multicast block ACK setup request e.g., Multicast (Mcst) ADD Block ACK (ADDBA) request
  • ADDBA ADD Block ACK
  • Mcst ADDBA response e.g., Mcst ADDBA response
  • Fig. 1 is a block diagram illustrating an example of a format of a Mcst ADDBA request frame or a Mcst ADDBA response frame (e.g., conventional ADDBA request frame or ADDBA response frame) which can be used in the process of determining a block ACK scheme.
  • the conventional ADDBA request/response frame includes a frame control field, a duration field, a Destination Address (DA) field, a Source Address (SA) field, a Basic Service Set Identifier (BSSID) field, a sequence control field, a frame body field, and a Frame Check Sequence (FCS) field.
  • the frame format of Fig. 1 is the same as the conventional management frame format used in a wireless network, and thus detailed descriptions thereof will be omitted.
  • Fig. 2 illustrates the frame control field of the ADDBA request/response frame of
  • the frame control field includes a protocol version subfield, a type subfield, a subtype subfield, a 'To DS' subfield, a 'From DS' subfield, a 'More Fragment' subfield, a 'Retry' subfield, a 'Pwr MgL' subfield, a 'More Data' subfield, a 'WEP' or 'Protected Data' subfield, and an 'Order' subfield.
  • the type subfield and the subtype subfield are provided to indicate frame functions. More specifically, according to information inserted into the type subfield, it is possible to recognize to which frame the frame of Fig.
  • each frame type includes a plurality of defined subtypes.
  • Table 1 shows an example of valid combinations of information elements that can be contained in the type subfield and the subtype subfield.
  • the ADDBA request/response frame has a type subfield indicating a management frame and a subtype subfield indicating an action frame.
  • the type subfield and the subtype subfield may respectively contain '01' and 1I lOl 1 .
  • the frame body field of the ADDBA request frame may include information elements shown in Table 2 below. [43] Table 2
  • the frame body field of the ADDBA request frame includes a category subfield, an action subfield, a dialog token subfield, a block ACK parameter set subfield, a block ACK timeout value subfield, and a block ACK starting sequence control subfield.
  • the category subfield is set to a value (e.g., '3') indicating a block ACK
  • the action subfield is set to a value (e.g., '0') indicating an ADDBA request frame.
  • the frame body field of the ADDBA response frame may include information elements shown in Table 3 below. [46] Table 3
  • the frame body field of the ADDBA response frame includes a category subfield, an action subfield, a dialog token subfield, a status code subfield, a block ACK parameter set subfield, and a block ACK timeout value subfield.
  • the category subfield is set to a value (e.g., '3') indicating a block ACK
  • the action subfield is set to a value (e.g., T) indicating an ADDBA response frame.
  • the Mcst ADDBA request/response frame used in a setup procedure included in a multicast block ACK process has a format similar to the ADDBA request/response frame used in a setup procedure included the aforementioned block ACK procedure by unicast.
  • a recipient address is allowed to be set to a multicast address.
  • the Mcst ADDBA request/response frame may further include an additional unit (e.g., buffer size subfield and/or setup subfield) which is not included in the conventional ADDBA request/response frame.
  • the Mcst ADDBA request/response frame is a new action frame which is different from the conventional ADDBA request/response frame.
  • the ADDBA request/response frame may be used to setup and manage a multicast block ACK procedure, more particularly, to generate a multicast group for a multicast block ACK service, to manage the group, to be registered to the group, and to be deregistered from the group.
  • action frame fields of the ADDBA request/ response frame described with reference to Fig. 1, Fig. 2, and Tables 1 to 3 are used without alteration.
  • a specific multicast address is used for a recipient address field of the Mcst ADDBA request/response frame.
  • the category subfield and/or the action subfield of Tables 2 and 3 may be set to reserved values indicating the Mcst ADDBA request frame and the Mcst ADDBA response frame.
  • a subfield for new information is added to the ADDBA request/response frame for setting a block ACK by unicast.
  • the new information may contain a buffer size subfield for determining a data burst size and/or a setup subfield.
  • the frame body field of the Mcst ADDBA request frame which is newly defined according to one aspect of the present embodiment, may include information elements shown in Table 4.
  • the frame body field of the Mcst ADDBA request frame includes a category subfield, an action subfield, a dialog token subfield, a multicast block ACK parameter set subfield, a multicast block ACK timeout value subfield, and a multicast block ACK starting sequence control subfield.
  • the category subfield may be set to a value (e.g., '4') indicating a multicast block ACK
  • the action subfield may be set to a value (e.g., '0') indicating a Mcst ADDBA request frame.
  • the frame body field of the Mcst ADDBA response frame which is newly defined according to one aspect of the present embodiment, may include information elements shown in Table 5.
  • the frame body field of the Mcst ADDBA response frame includes a category subfield, an action subfield, a dialog token subfield, a status code subfield, a multicast block ACK parameter set subfield, and a multicast block ACK timeout value subfield.
  • the category subfield may be set to a value (e.g., '4') indicating a multicast block ACK
  • the action subfield may be set to a value (e.g., T) indicating a Mcst ADDBA response frame.
  • a management frame for ending a block ACK determined by multicast may include information elements shown in Table 6.
  • the frame body field of the Mcst DELBA frame includes a category subfield, an action subfield, a multicast DELBA parameter set subfield, and a reason code subfield.
  • the category subfield may be set to a value (e.g., '4') indicating a multicast block ACK
  • the action subfield may be set to a value (e.g., '2')indicating a Mcst DELBA frame.
  • a procedure for managing a group e.g., multicast block ACK group
  • a multicast address for the multicast service is assumed to be selected in a higher layer than a Medium Access Control (MAC) layer.
  • the multicast address is reported for a multicast originator and a potential recipient. It will be assumed that the multicast block ACK service according to the present embodiment is provided to stations registered to the multicast group.
  • MAC Medium Access Control
  • an originator transmitting multicast data determines a new group (e.g., multicast block ACK group) for multicast block ACK prior to the transmission of the multicast data.
  • the multicast block ACK group includes stations which intend to use a multicast block ACK service according to the present embodiment and may be formed by exchanging a multicast block ACK setup request frame and a multicast block ACK setup response frame.
  • a setup procedure of the multicast block ACK group may include a process for matching a maximal data burst size with respect to all group members belonging to the multicast block ACK group.
  • an originator does not belong to the multicast group in general, the originator may be a station that belongs to the multicast group.
  • FIG. 3 is a message flow diagram illustrating a procedure for generating a multicast block ACK group and for transmitting multicast data by using the generated multicast block ACK group according to an embodiment of the present invention.
  • an originator transmits a multicast block ACK setup request frame (i.e., Mcst ADDBA request frame) to recipients more than two times (step S31).
  • the originator may be either a non-AP station (STA) or an Access Point (AP), where the STA is an arbitrary function medium including an MAC layer in compliance with an IEEE 802.11 standard and a physical layer interface for a wireless medium.
  • STA may also be referred to as a radio station, a Wireless Transmit/Receive Unit (WTRU), a User Equipment (UE) unit, a Mobile Station (MS), a mobile subscriber unit, and so on.
  • the AP may also be referred to as a central controller, a Base Station (BS), a node-B, a site controller, and so on.
  • the recipients are STAs registered to the multicast group.
  • the Mcst ADDBA request frame may be transmitted two times or more (e.g., mM- cstlnitNumber times).
  • the reason of transmitting the Mcst ADDBA request frame several times is to ensure reception for all recipients. That is, if the originator transmits the Mcst ADDBA request frame only one time, it is not ensured that all recipients can properly receive the Mcst ADDBA request frame transmitted from the originator. Furthermore, a probability of receiving the Mcst ADDBA request frame transmitted from all recipients increases in proportion to the number of times of transmission. The number of times of transmission of the Mcst ADDBA request frame has to be determined in consideration of channel usage efficiency.
  • the originator operates a timer after a last Mcst ADDBA request frame is transmitted. An expiration time of the timer is appropriately set. For example, the expiration time of the timer may be mMcs- tlnitTimeout.
  • each recipient transmits a multicast block ACK setup response frame (e.g., Mcst ADDBA response frame) (step S32).
  • Mcst ADDBA response frame e.g., Mcst ADDBA response frame
  • Each recipient may be a non-AP STA.
  • the Mcst ADDBA response frame is transmitted within the aforementioned expiration time of the timer (e.g., mMcs- tlnitTimeout).
  • an Immediate Block ACK (Imm-ACK) policy is applied between the originator and a recipient, STAs in association with a multicast address may immediately transmit the Mcst ADDBA response frame according to the Imm- ACK policy.
  • Imm-ACK Immediate Block ACK
  • the Mcst ADDBA response frame may further include information on a maximal buffer size of available recipients for multicast traffic.
  • each recipient can inform the originator of a maximal size of a multicast data packet (data burst) that can be received at once without having to transmit a block ACK frame. This is used when a maximal burst size is determined in subsequent step S33.
  • the originator recognizes members of the multicast group.
  • the originator determines the maximal burst size allowed in the transmission of the multicast data packet (step S33). For the maximal burst size, a minimal buffer size may be selected by using received buffer size information.
  • the present invention is not limited thereto.
  • the originator transmits the Mcst ADDBA request frame several times (e.g., mMcstlnitNumber times) to the recipients (step S34). Similar to the Mcst ADDBA request frame transmitted in step S31, the Mcst ADDBA request frame transmitted in this step has a destination address which is set to a multicast group address. In addition, to ensure successful reception, transmission is performed several times. However, unlike the Mcst ADDBA request frame of step S31, the Mcst ADDBA request frame in this step further includes a buffer size subfield, which is set to the burst size determined in step S33, and a setup subfield which is set to T. The setup subfield indicates that specific information is contained in the buffer size subfield. In addition, the setup subfield indicates that a multicast data packet is ready to be transmitted after step S34.
  • a buffer size subfield which is set to the burst size determined in step S33
  • a setup subfield which is set to T. The setup subfield indicates that specific information
  • the originator starts to transmit the multicast data (step S35).
  • the transmission of the multicast data is performed according to a conventional multicast procedure.
  • a size of the transmitted data packet cannot exceed a value indicated by the buffer size subfield of the ADDBA request frame transmitted in step S34.
  • each recipient Upon successfully receiving the multicast data, each recipient transmits a Block
  • step S32 the new station transmits to an originator a multicast block ACK setup response (e.g., Mcst ADDBA response) frame according to a conventional response procedure (e.g., Imm-ACK policy).
  • Mcst ADDBA response e.g., Mcst ADDBA response
  • a conventional response procedure e.g., Imm-ACK policy
  • information on a buffer size of a new recipient may be further included in a multicast block ACK setup response frame transmitted from the new recipient to the originator. If the information on a maximal buffer size is not included in the Mcst ADDBA response frame transmitted from the new recipient to the originator, the originator may additionally transmit, to the new recipient, unicast traffic for requesting the information on the maximal buffer size of the recipient.
  • the buffer size information is used to determine the maximal burst size (see step S33). For example, the originator may compare a predetermined maximal burst size with the maximal buffer size of the new recipient, and thus may determine a smaller value as a new maximal burst size.
  • the originator transmits to the recipient a buffer size subfield and a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) several times.
  • the multicast block ACK setup request frame includes a destination address field which is set to a multicast address, a buffer size subfield which is set to a newly determined maximal burst size, and a setup field which is set to T. Thereafter, multicast data transmission can begin as described in step S35.
  • a procedure will be described in brief, in which a registered station is deregistered from a multicast block ACK group according to an embodiment of the present invention.
  • the station transmits to an originator a Mcst leave management frame according to the Imm-ACK policy by using a conventional 802.11 standard.
  • the originator may exclude the station from the multicast group of the originator, which will be described in below.
  • BBS Basic Service Set
  • an originator transmits data to a recipient by using either a direct multicast method or an indirect multicast method.
  • the originator transmits data directly to the recipient.
  • the originator transmits data to the recipient via an AP.
  • a ToDS field of a transmission frame is set to T.
  • the originator can manage its group in the same manner as in an Independent BBS (IBBS) mode (or ad-hoc mode). That is, the originator can manage a multicast block ACK group according to the procedure described in detail with reference to Fig. 3.
  • IBBS Independent BBS
  • the originator may manage its group by transmitting all management frames including a ToDS bit which is set to T. All pieces of multicast data may be transmitted through the AP, which causes an additional overhead. In this case, only the multicast originator transmits its own traffic to the AP by using unicast transmission, and the AP relays traffic by multicast. That is, only the AP is a transmitter of multicast data.
  • the multicast data can be transmitted by using either the direct multicast method or the indirect multicast method.
  • the non-AP STA it is not possible for the non-AP STA to continuously transmit the multicast data by using the direct multicast method. This is because a hidden station may result in a problem when the direct multicast method is used. Therefore, when the originator of the multicast data is the non-AP STA, it is preferable that the originator first checks whether there is an opportunity for directly managing the multicast group and then transmits the data by using the direct multicast method only when the direct management is possible. In order to check whether the direct management is possible, the originator may use the following method, which is only an example.
  • the originator transmits a multicast block ACK setup request frame (e.g.,
  • Mcst ADDBA request frame in which a ToDS field is set to '0', several times (e.g., mMcstlnitNumber times). Since the ToDS field is set to '0', the transmission of the Mcst ADDBA request frame corresponds to direct transmission.
  • the originator transmits to an AP a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) including a ToDS bit (set to T) several times (e.g., mMcstlnitNumber times), and the AP retransmits the received multicast block ACK setup request frame to stations of the multicast group several times (e.g., mMcstlnitNumber times).
  • Mcst ADDBA request frame including a ToDS bit (set to T) several times (e.g., mMcstlnitNumber times)
  • the AP retransmits the received multicast block ACK setup request frame to stations of the multicast group several times (e.g., mMcstlnitNumber times).
  • the ToDS field of the frame transmitted by the originator is set to T, the transmission of the Mcst ADDBA request frame corresponds to indirect transmission.
  • the originator After performing the aforementioned direct transmission and indirect transmission, the originator determines whether the number of stations that respond to the originator is constant for each transmission method. If the determination result shows that the number of stations is constant for the two methods, a hidden node problem does not occur. Thus, the originator recognizes that the multicast group can be directly managed. In this case, the originator transmits the multicast data by using the direct transmission method. On the other hand, if the number of stations that respond to the originator is different between the direct transmission and the indirect transmission, the originator selects the indirect transmission. In this case, the originator may report a member list of the multicast block ACK group to the AP by using a special Mcst group announcement frame.
  • a potential multicast recipient may be in a power-save mode or in a switch off state.
  • the potential multicast recipient may intend to be registered to the multicast block ACK group some time later. In this case, if the potential recipient corresponds to a hidden node with respect to the originator and if the originator transmits a multicast frame by using the direct transmission method, then the potential recipient may not be able to be registered to the multicast block ACK group.
  • the originator may periodically transmit a Mcst probe request frame including a ToDS field (set to T).
  • a new recipient transmits a multicast block ACK setup response frame (e.g., Mcst ADDBA response frame) including a ToDS field (set to T) to the originator via the AP.
  • the originator Upon receiving the multicast block ACK setup response frame from the new recipient, the originator recognizes the new recipient as a member of a multicast block ACK group of the originator, and transmits multicast traffic to the new recipient via the AP.
  • a buffer size of the recipient may be less than a predetermined multicast burst size.
  • the originator may transmit a multicast block ACK setup request frame (e.g., Mcst ADDBA request frame) including a setup field (set to T) mMcstlnitNumber times, so that a burst size of the new recipient is set to a buffer size for a corresponding multicast block ACK service.
  • a multicast block ACK setup request frame e.g., Mcst ADDBA request frame
  • T setup field
  • the originator may report a member list of a multicast group to the AP by using the Mcst group list announcement frame several times.
  • the originator is a non-AP STA in an IBSS (or ad-hoc network) mode, and, among recipients registered to a multicast block ACK group, there is no recipient having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator does not exist).
  • the originator is a non-AP STA in an IBSS (or ad-hoc network), and, among recipients registered to a multicast block ACK group, there is one or more recipients having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator exists).
  • the originator is an AP in a BBS mode or a non-AP STA in the BBS mode, and, among recipients registered to a multicast block ACK group, there is no recipient having a neighboring station hidden from the originator (i.e., a neighboring station of a recipient hidden from the originator does not exist).
  • the originator is a non-AP STA in a BBS mode, and, among recipients registered to a multicast block ACK group, when there is one or more recipients having a neighboring station hidden from the originator, multicast traffic is transmitted by using a direct multicast method (i.e., a neighboring station of a recipient hidden from the originator exists, and multicast traffic is transmitted by using the direct multicast method).
  • a direct multicast method i.e., a neighboring station of a recipient hidden from the originator exists, and multicast traffic is transmitted by using the direct multicast method.
  • a direct multicast procedure will now be described for the above network conditions 1) and 3), that is, when a multicast is performed between STAs (or between an STA and an AP) which can perform direct communication with each other and when there is no recipient having a neighboring station hidden from the originator.
  • the originator may transmit only one RTS frame for one or more arbitrary recipients corresponding to a leader. It is not necessary to choose the leader in this manner if an RTS noise-induced error probability is significantly small. In addition, when choosing the leader, the leader may be randomly chosen.
  • Fig. 4 is a message flow diagram for illustrating an RTS-I procedure according to an embodiment of the present invention.
  • the RTS-I procedure includes an RTS/CTS frame exchange procedure and a multicast frame transmission procedure.
  • Steps S42 to S45 shown in the left portion of Fig. 4 show the case where the originator has received a CTS frame from a leader in response to an RTS frame.
  • Steps S46 to S47 shown in the right portion of Fig. 4 show the case where the originator has failed to receive the CTS frame from the leader.
  • the RTS- 1 procedure according to the present embodiment will be described with reference to Fig. 4.
  • the originator chooses a leader of a multicast group from recipients Rl, R2, and R3 registered to the multicast group (or multicast block ACK group) including a plurality of STAs (step S41).
  • the recipient Rl is assumed to be chosen as the leader.
  • the originator transmits to the leader RI a unicast RTS frame including a Network Allocation Vector (NAV) which is set to a proper time value (step S42).
  • NAV Network Allocation Vector
  • the leader Rl Upon successfully receiving the RTS frame, the leader Rl transmits a CTS frame in response to the received RTS frame (step S43).
  • NAV Network Allocation Vector
  • step S44 HiddenThresholdCounter and McstExclusionCounter related to the current leader Rl are reset to '0' (step S45).
  • the originator transmits an RTS frame to the leader Rl.
  • the originator cannot receive a CTS frame, which is a response frame for the RTS frame, from the leader. If this is the case, according to the present embodiment, the originator performs backoff on multicast data to be transmitted, and increments HiddenThresholdCounter related to the current leader (step S46).
  • the HiddenThresholdCounter reaches an arbitrary threshold, e.g., mHiddenThreshold, the originator performs an active scan process in which a hidden terminal (to be described below) is actively searched for (step S47).
  • the multicast data transmission performed in step S44 may fail due to interference or fading. Therefore, even when the method of Fig. 4 is used, there is a need to check whether the multicast data has been successfully transmitted with respect to each STA registered to the multicast group.
  • the checking process can be performed without restriction.
  • a block ACK request frame e.g., Block ACK Request (BAR) frame
  • BAR Block ACK Request
  • Fig. 5 is a message flow diagram illustrating an ACK procedure according to an embodiment of the present invention. The ACK procedure will now be described with reference to Fig. 5.
  • an originator After transmitting multicast data, an originator sequentially transmits a BAR frame to all recipients (step S51). Upon receiving the transmitted multicast data, the recipients transmits a Block ACK (B-ACK) frame to the originator in response to the received BAR frame (step S52). If a B-ACK frame is received from a specific recipient, the originator resets McstExclusionCounter related to the specific recipient to '0' (step S53). On the other hand, if no B-ACK frame is received from the specific recipient, the originator increments McstExclusionCounter related to the specific recipient (step S54). In this case, the McstExclusionCounter reaches a predetermined threshold (e.g., McstExclusionCounter threshold), the originator excludes the recipient from the multicast group (step S55).
  • a predetermined threshold e.g., McstExclusionCounter threshold
  • the originator prepares frames for next burst transmission, wherein the frames include data frames which are not acknowledged by all recipients, and for this, the originator performs backoff. All of non-acknowledged data frames, each of which packet lifespan is not yet expired, may be retransmitted in a next transmission round by the originator. During the burst transmission, new frames and the retransmitted frames may exist in the same burst.
  • Fig. 6 is a view for explaining a multicast transmission procedure according to an embodiment of the present invention, when there is no recipient having a neighboring station hidden from an originator.
  • the RTS- 1 procedure and the ACK procedure respectively illustrated in Fig. 4 and Fig. 5 are included in the procedure of Fig. 6.
  • the procedure of Fig. 6 includes an RTS-CTS exchange procedure for reliable multicast transmission, a multicast data transmission procedure, and an ACK procedure.
  • the procedure of Fig. 6 shows a case in which three or more recipients are registered to a multicast block ACK group, and one RTS leader exists.
  • the RTS leader is an originator that transmits a CTS frame.
  • the RTS leader is a station that is in charge of RTS-CTS frame exchange.
  • the three recipients are stations to which BAR is transmitted by the originator. The stations respond to the BAR by sending B-ACK.
  • the multicast procedure according to the present embodiment includes an RTS/CTS frame exchange procedure performed one time by using unicast traffic, a multicast data transmission procedure using multicast traffic, and a BAR/ B-ACK exchange procedure performed a plurality of times (corresponding to the number of recipients registered to the multicast block ACK group) by using unicast traffic.
  • the originator performs the RTS-CTS exchange procedure with respect to one RTS leader. Further, the originator transmits a plurality of pieces of data by multicast and thereafter exchanges the BAR and B-ACK frames with three recipients.
  • the present invention is not limited thereto.
  • the originator may exchange the RTS/CTS frame with the RTS leader. Further, the originator may transmit a plurality of pieces of data and thereafter exchange the BAR frame and the B-ACK frame with all stations belonging to the multicast block ACK group.
  • the originator may exchange the RTS/CTS frame with all stations belonging to the multicast group and may exchange the BAR frame and the B-ACK frame with at least one of stations belonging to the multicast group.
  • the originator exchanges the RTS/
  • an AP that relays multicast traffic can listen from all stations existing within a BBS.
  • the following data burst transmission method is proposed in the present embodiment.
  • Fig. 7 is a message flow diagram illustrating an indirect multicast procedure according to an embodiment of the present invention. The indirect multicast procedure will be described hereinafter with reference to Fig. 7.
  • an originator is an STA which is one component of the BBS and transmits an RTS frame including a destination address field that is set to a multicast address and a ToDS field that is set to T (step S61). Since the ToDS field is set to T, the RTS frame is first transmitted to an AP. The AP responds to the received RTS frame by sending a CTS frame (step S62).
  • the originator transmits a group of data frames (i.e., data burst) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S63).
  • the originator transmits a block ACK request frame (e.g., BAR frame) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S64).
  • the AP responds to the BAR frame by sending a block ACK frame (e.g., B-ACK frame) (step S65).
  • a block ACK frame e.g., B-ACK frame
  • the AP After receiving the multicast burst by performing the aforementioned processes, the AP performs a multicast procedure according to the present embodiment in the same manner as the aforementioned direct multicast procedure. More specifically, by using the multicast group member list obtained from the multicast group list announcement frame, the AP performs multicast transmission according to the RTS-I procedure of Fig. 4 and the ACK procedure of Fig. 5.
  • the RTS/CST frame exchange procedure and the multicast burst transmission procedure are performed between the originator and the AP. Thereafter, the RTS-I procedure and the block ACK procedure are performed by regarding the AP as the originator. That is, multicast data is transmitted from the originator to the AP, and then the AP transmits the received multicast data for STAs registered to the multicast group.
  • a time for transmitting a multicast data packet to the AP may be greater than a time for transmitting the packet from the AP to all multicast recipients.
  • ACK policy (e.g., Imm-ACK policy) is used in the indirect multicast procedure according to the present embodiment.
  • the AP sends a block ACK frame and thereafter ensures reliable transmission of the data burst.
  • an originator that initially transmits the multicast data cannot recognize a packet loss even if a packet is lost while the packet is multicast from the AP.
  • a modified indirect multicast procedure is proposed. This is to allow an originator to recognize packet loss when a packet is lost and to improve end-to-end reliability.
  • Fig. 8 is a message flow diagram illustrating an indirect multicast procedure modified according to another embodiment of the present invention.
  • the modified indirect multicast procedure will now be described with reference to Fig. 8.
  • the modified indirect multicast procedure proposed in the present embodiment employs a delayed block ACK method.
  • an originator is an STA which is one component of the BBS and transmits an RTS frame including a destination address field that is set to a multicast address and a ToDS field that is set to T (step S71). Since the ToDS field is set to T, the RTS frame is first transmitted to an AP. The AP responds to the received RTS frame by sending a CTS frame (step S72).
  • the originator After the RTS/CTS frame is exchanged between the originator and the AP, the originator transmits a set of data frames (i.e., data burst) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S73). Upon completing the transmission of the data burst, the originator transmits a block ACK request frame (e.g., BAR frame) including a destination address field which is set to the multicast address and a ToDS field which is set to T (step S74).
  • a set of data frames i.e., data burst
  • a block ACK request frame e.g., BAR frame
  • the AP By using the multicast group member list obtained from the multicast group list announcement frame transmitted by the originator, the AP performs multicast transmission according to the RTS-I procedure of Fig. 4 and the ACK procedure of Fig. 5 (step S75). Subsequently, according to a delayed B-ACK policy, the AP transmits the block ACK frame to the originator (step S76).
  • a data burst is transmitted to STAs which are recipients of multicast data, and in response thereto, the AP sends a block ACK frame to the originator. Therefore, by using the block ACK frame transmitted from the AP, the originator can recognize whether transmitted multicast data packets are correctly transmitted to all recipients or whether some of the packets are lost. If multicast transmission is not successful, for example, when some packets of data burst are not transmitted to all recipients, the originator may report this to a higher layer and/or may start retransmission of a corresponding packet.
  • An embodiment of the present invention to be described hereinafter relates to the aforementioned network conditions 2) and 5).
  • the network conditions 2) and 5 there are one or more recipients having neighboring stations (hidden nodes) hidden from the originator.
  • the originator has to know whether all recipients of multicast data are ready to receive the multicast data.
  • the following method is proposed which extends a protocol used in the aforementioned case (1) "Direct Multicast Procedure - When a recipient does not have a neighboring station hidden from an originator.” More specifically, in this embodiment, allocation of a plurality of (or at least one) RTS- leaders is proposed. The RTS-leaders are chosen as recipients having at least one neighboring station (i.e., hidden node) hidden from the originator. Furthermore, the originator transmits a unicast RTS frame to all RTS-leaders chosen before multicast data is transmitted.
  • the RTS-leaders respond to this by transmitting a CTS frame.
  • the originator If the originator properly receives the CTS frame from a current RTS-leader, the originator resets McstExclusionCounter related to that RTS-leader to '0', and transmits the RTS frame to another RTS-leader (if it exists) or starts multicast transmission.
  • the originator If the originator fails to properly receive the CTS frame from the RTS-leader in response to the RTS frame, the originator increments McstExclusionCounter related to that RTS-leader. When the McstExclusionCounter reaches McstExclusionCounter threshold, the originator excludes the recipient from the multicast group. Thereafter, the originator performs backoff.
  • the originator After transmitting the multicast data, the originator performs the ACK procedure shown in Fig. 5.
  • Fig. 9 is a view for explaining an RTS-CTS exchange procedure, a multicast data transmission procedure, and an ACK procedure, each of which is performed for reliable multicast data transmission when there is a recipient having a neighboring station hidden from an originator as described above.
  • recipients for receiving multicast data are three STAs, and among them, two recipients have at least one neighboring station hidden from the originator.
  • the originator may choose the two STAs having hidden nodes as RTS-leaders.
  • a multicast procedure includes an RTS/CTS frame exchange procedure which is performed two times by using unicast traffic, a multicast data transmission procedure which is performed by using multicast traffic, and a BAR/B-ACK exchange procedure which is performed a plurality of times (corresponding to the number of recipients registered to a multicast block ACK group) by using unicast traffic.
  • the RTS/CTS frame exchange procedure is performed two times between the originator and an RTS-leader having a hidden node.
  • the RTS/CTS frame exchange procedure is carried out by the same number of times as the number of RTS-leaders having hidden nodes.
  • the originator does not transmit block ACK request frames (e.g., BAR frames) to these recipients. Therefore, in the present embodiment, an ACK overhead can be reduced.
  • block ACK request frames e.g., BAR frames
  • an originator has to receive a B-ACK frame from each station.
  • time delay may be relatively long. Due to such problem, it may not be proper to allow the B-ACK frame to be received from each recipient, in particular, for some applications (e.g., real time streaming for wireless TV) used by many recipients. Therefore, when using applications susceptible to delay, there is a need to address a delay problem caused by a B-ACK procedure performed for each recipient.
  • a data burst decreases, and the aforementioned block ACK procedure is modified.
  • the B-ACK procedure may be modified in the following manner.
  • a multicast data transmitter i.e., an originator in the case of direct multicast and an AP in the case of indirect multicast
  • the packet loss statistics are collected without any restriction.
  • the transmitter transmits BARs to Nl recipients (where Nl is a natural number greater than or equal to 1) having the highest packet loss probability and N2 recipients (where N2 is a natural number greater than or equal to 0) which are randomly chosen from remaining recipients other than the Nl recipients.
  • This method may be performed with some alterations.
  • a burst size can be limited to one packet. However, reliability may not be sufficiently ensured in this manner.
  • Nl, N2, and the burst size it is possible to optimize.
  • Fig. 10 illustrates a simulation scenario in a hot spot.
  • recipients are uniformly distributed in a hot spot zone and operate under different conditions due to a path loss phenomenon.
  • Fig. 11 illustrates a simulation scenario in a narrow ring. In Fig. 11, all recipients have almost the same Signal-to-Noise Ratio (SNR).
  • SNR Signal-to-Noise Ratio
  • Table 7 shows a simulation environment for a simulation scenario in a hot spot and a narrow ring illustrated in Fig. 10 and Fig. 11.
  • Indices indicating performance and reliability include an M-bit throughput per second in a payload, an average transmission time (e.g., an average time for a packet service), an Average Percent of Packet Losses (APPL), and a Maximal Percent of Packet Losses (MPPL).
  • an average transmission time e.g., an average time for a packet service
  • an Average Percent of Packet Losses APPL
  • MPPL Maximal Percent of Packet Losses
  • a transmitting-side station in the simulation model includes a variable rate data source block, a modulator bank block, an Orthogonal Frequency-Division Multiplexing (OFDM) frame assembler block, an Inverse Fast Fourier Transform (IFFT) block, an OFDM frame multiplexing block.
  • a receiving- side station in the simulation model includes an OFDM frame demultiplexing block, an FFT block, a frequency domain equalizing block, an OFDM frame de-assembler block, and a demodulator bank block.
  • the PER is computed by using the output of the variable rate data source block of the transmitting-side station and the output of the demodulator bank block of the receiving-side station.
  • the SNR is estimated by using the demodulator bank block of the receiving- side station.
  • Table 8 shows a simulation result obtained by using the aforementioned simulation model in a hot stop.
  • Fig. 12 and Fig. 13 are graphs showing simulation results related to a throughput with respect to an average transmission time in a hot spot scenario.
  • the higher the number M of recipients the higher the PER experienced by ACK leaders, resulting in the increase in the number of retires. As a result, an average transmission time and a throughput decrease.
  • Fig. 14 and Fig. 15 are graphs showing simulation results related to an average percent of packet losses and a maximal percent of packet losses in a hot spot scenario.
  • reliability becomes higher along with the decrease in the throughput.
  • optimization can be achieved by fixing the number of ACK leaders.
  • Nl may be set to a total number of ACK leaders and N2 may be set to '0'.
  • Table 9 shows a simulation result by using the simulation model in a ring scenario. [161] Table 9
  • Fig. 16 and Fig. 17 show simulation results related to a throughput and an average transmission time in a ring scenario.
  • the throughput and the average transmission time are independent from the number of recipients, and very slightly depend on a ratio of N1/N2 along with fixed N1+N2.
  • an intensive control mode may be used so that an RTS/CTS frame exchange procedure is prevented from being performed several times.
  • the intensive control mode may be either a Point Coordination Function (PCF) or a Hybrid coordination function Controlled Channel Access (HCCA), but the present invention is not limited thereto.
  • PCF Point Coordination Function
  • HCCA Hybrid coordination function Controlled Channel Access
  • TXOP Transmission Opportunity
  • [168] for implementation of reliable multicast, it is very important to recognize hidden terminals.
  • multicast data transmission is possible after an RTS/CTS frame is exchanged with only one recipient. This is because the RTS/CTS frame is very short, and thus packet loss probability (caused by noise) can be negligible.
  • a multicast transmitter has to assume that all recipients may have neighboring stations hidden from the transmitter, and an RTS frame has to be transmitted to all recipients, which leads to significant overhead.
  • the transmitter may transmit the RTS frame only to that recipient. If there are two recipients having hidden neighboring stations, it is enough to transmit only two RTS frames to the two recipients.
  • the originator/transmitter can transmit RTS frames without deterioration in reliability only to recipients having neighboring stations hidden from the originator/transmitter. Thus, overall RTS/CTS overhead can be reduced by recognizing hidden terminals.
  • a hidden terminal may be detected in the following manner.
  • an originator receives an RTS frame transmitted from a station A to a station B
  • the originator may not receive a CTS frame which is transmitted in response thereto after a Short Inter-Frame Space (SIFS). This is because the station B is hidden from the originator.
  • SIFS Short Inter-Frame Space
  • the originator receives a data frame transmitted from the station A to the station B but does not receive ACK transmitted in response thereto after SIFS.
  • a passive scan Such a method for detecting a hidden terminal is called a passive scan.
  • a threshold i.e., mHiddenDetectThreshold
  • the originator may conclude that a multicast recipient has at least one hidden neighboring station.
  • an originator transmits a special InitProbe command including a list of all recipients to all (or some) of the recipients.
  • the recipients transmit probe packets based on the Imm-ACK policy to neighboring stations which are not present in the list. For example, information on the neighboring stations may be obtained by exchanging hello messages defined in an ad- hoc routing protocol.
  • the originator may conclude that a corresponding recipient has a hidden neighboring station. If the originator does not receive the probe packet from the recipient, the originator may exclude the recipient from the multicast group. Such an active scan procedure may be periodically performed when HiddenThresholdCounter reaches mHiddenThreshold, as described above in step S47 of Fig. 4. [178] Although exemplary embodiments of the present invention have been described with reference to the drawings, the present invention is not limited thereto.
  • a block ACK request frame (e.g., Mcst ADDBA request frame) that is a new action frame.
  • Mcst ADDBA request frame e.g., Mcst ADDBA request frame
  • an access method based on existing ARQ is partially provided as a background, analysis there of is performed under various conditions, and effectiveness thereof is determined.
  • the present invention also apply to the case where a plurality of access methods based on existing ARQ are combined or where some features thereof are selected to be combined.
  • a new MAC tool is introduced to provide reliable multicast.
  • a new mechanism is proposed which manages a multicast group and transmits multicast data in a reliable and effective manner.
  • a station and an AP have been described as an example, wherein the station is equipped with a wireless network interface card and performs operations of physical and MAC layers based on an IEEE 802.11 standard, and wherein the AP performs a wired/wireless interconnection bridge function that relays a frame from one station to another.
  • the station is equipped with a wireless network interface card and performs operations of physical and MAC layers based on an IEEE 802.11 standard, and wherein the AP performs a wired/wireless interconnection bridge function that relays a frame from one station to another.
  • this is for explanation purpose only, and thus, the present invention is not limited thereto.
  • the AP since the AP includes physical and MAC layers which are basically the same as those of the station, the AP can perform the same operation as the station. Thus, optionally, the AP may be regarded as the same as the station.
  • data is transmitted between stations belonging to a specific multicast group by using multicast
  • the present invention is not limited thereto.
  • data may be transmitted to stations, which are not specified in an applicable range, by using broadcast.
  • the present invention can improve reliability of broadcast data transmission while reducing overload, since the originator performs exchange of RTS and CTS or exchange of BAR and B-ACK with at least one of the stations.
  • a wireless Local Area Network (LAN) system has been described in the aforementioned embodiments as an example. Further, the present invention may also apply to a wireless network system including the wireless LAN system and may be im- plemented by combining the two systems or by using a totally different system. In addition, although the wireless network system may exist alone in the present invention, the wireless network system may inter-work with another wireless network system, a mobile communication network, a wired/wireless Internet, and so on.
  • LAN Local Area Network
  • a wireless LAN system may provide a roaming service by inter- working with a mobile communication network (e.g., a Wideband Code Division Multiple Access (WCDMA) network).
  • a mobile communication network e.g., a Wideband Code Division Multiple Access (WCDMA) network
  • WCDMA Wideband Code Division Multiple Access
  • DBDM Dual Band Duel Mode
  • the present invention is effectively used in a network device, a network protocol, and a user device, each of which is related to wireless communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé de fourniture d'un service multidestination dans un réseau radio d'une manière efficace et fiable. Le procédé multidestination consiste à émettre, par l'intermédiaire d'une première station, une pluralité de trames de données dans lesquelles un champ d'adresse de destination est établi par rapport à une adresse d'un groupe multidestination spécifique, et effectuer une procédure d'accusé de réception de bloc entre une ou plusieurs secondes stations coïncidant avec le groupe multidestination et la première station. L'étape de réalisation d'une procédure d'accusé de réception de bloc consiste à envoyer, par l'intermédiaire de la première station, une trame de demande d'accusé de réception de bloc à la seconde station, et d'envoyer, par l'intermédiaire de la seconde station, une trame de réponse d'accusé de réception de bloc qui indique si la pluralité de trames de données a bien été reçue en réponse à la trame de demande d'accusé de réception de bloc. La procédure d'accusé de réception de bloc est effectuée par diffusion individuelle et par rapport à toutes les stations coïncidant avec le groupe multidestination ou est effectuée par rapport à une ou plusieurs stations uniquement.
PCT/KR2007/003946 2006-08-17 2007-08-17 Procédure multidestination dans un réseau radio WO2008020731A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US82274206P 2006-08-17 2006-08-17
US60/822,742 2006-08-17
KR1020070018329A KR20080016420A (ko) 2006-08-17 2007-02-23 무선 네트워크에서 통신방법, 무선 네트워크에서스테이션의 통신방법 및 스테이션
KR10-2007-0018329 2007-02-23

Publications (1)

Publication Number Publication Date
WO2008020731A1 true WO2008020731A1 (fr) 2008-02-21

Family

ID=39082233

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2007/003946 WO2008020731A1 (fr) 2006-08-17 2007-08-17 Procédure multidestination dans un réseau radio

Country Status (1)

Country Link
WO (1) WO2008020731A1 (fr)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007122503A3 (fr) * 2006-04-24 2008-12-18 Nokia Corp Diffusion/multidiffusion fiable dans un réseau sans fil
WO2009157892A1 (fr) * 2008-06-23 2009-12-30 Thomson Licensing Atténuation de collision pour une transmission de multidiffusion dans des réseaux locaux sans fil
WO2009157901A1 (fr) 2008-06-26 2009-12-30 Thomson Licensing Appareil de demande d'accusé de réception et de transmission d'accusé de réception de données à multidestination dans des réseaux de zone locale sans fil
WO2009157902A1 (fr) 2008-06-26 2009-12-30 Thomson Licensing Procédé et appareil d’accusé de réception et de retransmission de données à multidestination dans des réseaux à zone locale sans fil
US20110128900A1 (en) * 2008-07-31 2011-06-02 Yong Ho Seok Method of performing power save multi-poll (psmp) procedure wireless local access network system and station supporting the procedure
US8462686B2 (en) 2008-06-23 2013-06-11 Thomson Licensing Apparatus for collision mitigation of multicast transmissions in wireless networks
CN103312469A (zh) * 2013-05-20 2013-09-18 华为技术有限公司 组播重传中的确认代表选择方法及装置
US8705383B2 (en) 2008-06-18 2014-04-22 Thomson Licensing Contention based medium reservation for multicast transmission in wireless local area networks
US8737281B2 (en) 2008-06-18 2014-05-27 Thomson Licensing Apparatus for multicast transmissions in wireless local area networks
EP2279595A4 (fr) * 2008-05-09 2014-06-11 Lg Electronics Inc Dispositif et procede de multidiffusion dans un reseau d acces local sans fil
US9197428B1 (en) 2010-11-24 2015-11-24 Nyse Arca Llc Methods and apparatus for requesting message gap fill requests and responding to message gap fill requests
WO2016032607A1 (fr) * 2014-08-28 2016-03-03 Intel IP Corporation Appareil, procédé et système de transmission en liaison montante multi-utilisateur
WO2016056684A1 (fr) * 2014-10-07 2016-04-14 엘지전자 주식회사 Procédé et appareil de rétablissement après erreurs d'un terminal dans un système de réseau hétérogène
US9602297B2 (en) 2007-03-12 2017-03-21 Nokia Technologies Oy Establishment of reliable multicast/broadcast in a wireless network
US9792649B1 (en) 2010-11-24 2017-10-17 Nyse Arca Llc Methods and apparatus for performing risk checking
US20180227136A1 (en) * 2015-09-29 2018-08-09 Tlv Co., Ltd. Data transmission system, management device, non-transitory recording medium recording data transmission program, and data transmission method
EP3203665A4 (fr) * 2014-09-30 2018-12-19 Kabushiki Kaisha Toshiba Circuit intégré pour communication sans fil, terminal de communication sans fil et procédé de communication sans fil
US20230344667A1 (en) * 2022-04-22 2023-10-26 International Business Machines Corporation Single-producer-multiple consumers synchronization and multicast data transfer

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020045217A (ko) * 2000-12-08 2002-06-19 이형도 폴링방식을 이용한 피씨아이카드의 데이타 수신여부확인방법
KR200419294Y1 (ko) * 2005-04-04 2006-06-16 인터디지탈 테크날러지 코포레이션 무선랜에서의 프레임 교환시의 응답성을 개선하는 장치

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20020045217A (ko) * 2000-12-08 2002-06-19 이형도 폴링방식을 이용한 피씨아이카드의 데이타 수신여부확인방법
KR200419294Y1 (ko) * 2005-04-04 2006-06-16 인터디지탈 테크날러지 코포레이션 무선랜에서의 프레임 교환시의 응답성을 개선하는 장치

Cited By (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007122503A3 (fr) * 2006-04-24 2008-12-18 Nokia Corp Diffusion/multidiffusion fiable dans un réseau sans fil
US10469999B2 (en) 2007-03-12 2019-11-05 Nokia Technologies Oy Establishment of reliable multicast/broadcast in a wireless network
US9602297B2 (en) 2007-03-12 2017-03-21 Nokia Technologies Oy Establishment of reliable multicast/broadcast in a wireless network
US9577838B2 (en) 2008-05-09 2017-02-21 Lg Electronics Inc. Device and method for multicast in wireless local access network
EP2279595A4 (fr) * 2008-05-09 2014-06-11 Lg Electronics Inc Dispositif et procede de multidiffusion dans un reseau d acces local sans fil
US8737281B2 (en) 2008-06-18 2014-05-27 Thomson Licensing Apparatus for multicast transmissions in wireless local area networks
US8705383B2 (en) 2008-06-18 2014-04-22 Thomson Licensing Contention based medium reservation for multicast transmission in wireless local area networks
US8553548B2 (en) 2008-06-23 2013-10-08 Thomson Licensing Collision mitigation for multicast transmission in wireless local area networks
WO2009157892A1 (fr) * 2008-06-23 2009-12-30 Thomson Licensing Atténuation de collision pour une transmission de multidiffusion dans des réseaux locaux sans fil
EP2506494A1 (fr) * 2008-06-23 2012-10-03 Thomson Licensing Atténuation de collision pour transmission de multidiffusion dans des réseaux locaux sans fil
US8462686B2 (en) 2008-06-23 2013-06-11 Thomson Licensing Apparatus for collision mitigation of multicast transmissions in wireless networks
CN102057608A (zh) * 2008-06-26 2011-05-11 汤姆逊许可公司 无线局域网中用于请求确认与传送多播数据确认的设备
US8514763B2 (en) 2008-06-26 2013-08-20 Thomson Licensing Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks
US8472365B2 (en) 2008-06-26 2013-06-25 Thomson Licensing Method and system for acknowledgement and retransmission of multicast data in wireless local area networks
WO2009157902A1 (fr) 2008-06-26 2009-12-30 Thomson Licensing Procédé et appareil d’accusé de réception et de retransmission de données à multidestination dans des réseaux à zone locale sans fil
WO2009157901A1 (fr) 2008-06-26 2009-12-30 Thomson Licensing Appareil de demande d'accusé de réception et de transmission d'accusé de réception de données à multidestination dans des réseaux de zone locale sans fil
US9198125B2 (en) 2008-07-31 2015-11-24 Lg Electronics Inc. Method of performing power save multi-poll (PSMP) procedure wireless local access network system and station supporting the procedure
US9078242B2 (en) * 2008-07-31 2015-07-07 Lg Electronics Inc. Method of performing power save multi-poll (PSMP) procedure wireless local access network system and station supporting the procedure
US20110128900A1 (en) * 2008-07-31 2011-06-02 Yong Ho Seok Method of performing power save multi-poll (psmp) procedure wireless local access network system and station supporting the procedure
US10439833B1 (en) * 2010-11-24 2019-10-08 Nyse Arca Llc Methods and apparatus for using multicast messaging in a system for implementing transactions
US9197428B1 (en) 2010-11-24 2015-11-24 Nyse Arca Llc Methods and apparatus for requesting message gap fill requests and responding to message gap fill requests
US9792649B1 (en) 2010-11-24 2017-10-17 Nyse Arca Llc Methods and apparatus for performing risk checking
US9760946B1 (en) 2010-11-24 2017-09-12 Nyse Arca Llc Methods and apparatus for detecting gaps in a sequence of messages, requesting missing messages and/or responding to requests for messages
CN103312469A (zh) * 2013-05-20 2013-09-18 华为技术有限公司 组播重传中的确认代表选择方法及装置
RU2662634C1 (ru) * 2014-08-28 2018-07-26 ИНТЕЛ АйПи КОРПОРЕЙШН Устройство, способ и система многопользовательских передач по восходящей линии
US9462607B2 (en) 2014-08-28 2016-10-04 Intel IP Corporation Apparatus, method and system of multi-user uplink transmission
WO2016032607A1 (fr) * 2014-08-28 2016-03-03 Intel IP Corporation Appareil, procédé et système de transmission en liaison montante multi-utilisateur
EP3203665A4 (fr) * 2014-09-30 2018-12-19 Kabushiki Kaisha Toshiba Circuit intégré pour communication sans fil, terminal de communication sans fil et procédé de communication sans fil
WO2016056684A1 (fr) * 2014-10-07 2016-04-14 엘지전자 주식회사 Procédé et appareil de rétablissement après erreurs d'un terminal dans un système de réseau hétérogène
US20180227136A1 (en) * 2015-09-29 2018-08-09 Tlv Co., Ltd. Data transmission system, management device, non-transitory recording medium recording data transmission program, and data transmission method
EP3358794A4 (fr) * 2015-09-29 2018-10-17 TLV Co., Ltd. Système de transmission de données, dispositif de gestion, programme de transmission de données et procédé de transmission de données
US10536290B2 (en) 2015-09-29 2020-01-14 Tlv Co., Ltd. Data transmission system, management device, non-transitory recording medium recording data transmission program, and data transmission method
US20230344667A1 (en) * 2022-04-22 2023-10-26 International Business Machines Corporation Single-producer-multiple consumers synchronization and multicast data transfer

Similar Documents

Publication Publication Date Title
WO2008020731A1 (fr) Procédure multidestination dans un réseau radio
US10880874B2 (en) Method for transmitting a response request frame and a response frame in a multi-user based wireless communication system
KR101271317B1 (ko) 무선랜에서의 멀티캐스트 장치 및 방법
KR101482087B1 (ko) 무선 근거리 통신망에서 멀티캐스트 수신 확인의 요청 및 수신 확인의 전송을 위한 장치
KR101451247B1 (ko) 무선 근거리 통신망에서 멀티캐스트 데이터의 수신 확인 및 재전송을 위한 방법 및 장치
CN107040356B (zh) 无线局域网中协作传输的方法及装置
EP2255484B1 (fr) Indicateur de nouvelles données pour paquets attribués en continu dans un système de communication
US20060056421A1 (en) Reducing latency when transmitting acknowledgements in mesh networks
US8619644B2 (en) Robust coding in multi-hop networks
JP2016540434A (ja) ワイヤレスネットワークにおけるマルチキャスト通信のためのシステムおよび方法
US10701686B1 (en) Protection mechanism for multi-user transmission
WO2018014649A1 (fr) Procédé et dispositif de réponse de transmission de données de multidiffusion et support de stockage informatique
Chen et al. HIMAC: High throughput MAC layer multicasting in wireless networks
US9007978B2 (en) Method and apparatus for improved multicast service
US8693361B2 (en) Method and apparatus for improved multicast service using feedback mobiles
Wang et al. Supporting MAC layer multicast in IEEE 802.11 n: Issues and solutions
US9148259B2 (en) Method and apparatus for improved multicast service using negotiated feedback
Kim et al. Rate-adaptive MAC protocol for wireless multicast over OFDMA-based MANETs
Xie et al. An improvement to the reliability of IEEE 802.11 broadcast scheme for multicasting in mobile ad networks
WO2017063449A1 (fr) Procédé pour déterminer un terminal caché dans des communications en duplex intégral, appareil et système correspondants
KR20080016420A (ko) 무선 네트워크에서 통신방법, 무선 네트워크에서스테이션의 통신방법 및 스테이션
Kim et al. Reliable wireless multicasting with minimum overheads in OFDM-based WLANs
Lau et al. Collision avoidance and recovery for multicast communications in ad hoc networks
Bokor Novel Results on MBMS Service Provisioning in UMTS/WLAN Heterogeneous Architectures

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07793550

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 07793550

Country of ref document: EP

Kind code of ref document: A1