Patent Description:
<CIT> describes methods and an apparatuses for multicast group address signaling using a MAC header for power save delivery in a wireless network. According to an example embodiment, a multicast management frame (e.g., a multicast <NUM>. 11n Power Save Multi Poll (PSMP) frame) may be transmitted to identify a scheduled multicast data transmission to one or more receiver nodes in a wireless network.

<CIT> describes systems and methods for multicast tunneling for mobile devices. The method comprises receiving a multicast packet directed to a plurality of mobile nodes, the mobile nodes being associated with a home subnet and identifying if any of the plurality of the mobile nodes are coupled to a subnet other than the home subnet, wherein each of the identified mobile nodes has an associated transmission path through which that mobile node can be reached.

Some multi-access media select a designated station such that stations can communicate with the designated station, but non-designated stations may not be able to communicate with each other. Thus, for reliable receipt of a broadcast message originating at a non-designated station, for example, the message may be unicast to the designation station, which then broadcasts it to other stations. An Access Point (AP) configured to implement an Institute for Electrical and Electronics Engineers (IEEE) <NUM> protocol (e.g., Wi-Fi) is an example of such a designated station. A large number of products including home entertainment systems and industrial control equipment that have both an IEEE <NUM> wireless station capability and a wired IEEE <NUM> Ethernet capability. IEEE <NUM> has a media operating in the gigabit per second range and has standardized security and quality of service improvements. As such, IEEE <NUM> links may be used as transit links inside a wireless network, and not just as a path to an end station at the end of a network. Additional information for an IEEE <NUM> wireless network may be as described in the IEEE <NUM> standard titled, "Part <NUM>: Wireless local area network (LAN) Medium Access Control (MAC) and Physical Layer (PHY) Specifications," and additional information for an Ethernet network may be as described in the IEEE <NUM> standard titled, "IEEE Standard for Ethernet,".

Transmitting multi-destination frames from an AP using the communication between an IEEE <NUM> AP and its associated station as a set of p2p transit link may be challenging. For example, when implementing a spanning tree or the like, an arbitrary sub-set of stations may receive the frame and the frame may not be sent back to the sender (e.g., reflection problem). Also, the frame may comprise different virtual local access networks (VLAN) identifier and/or other tagging identifiers to forward the frame to different stations. Some conventional networks may broadcast messages as a sequence of unicast messages to their intended recipients. However, the broadcast link may be blocked for other transmissions during each of the multiple unicast transmissions, which may result in significant channel blocking. Other conventional systems may use a designated station on a broadcast media link to configure other stations on that broadcast link by sending commands to other stations so as to control which other stations should receive messages. This may require a protocol between the designation station and every other station so that the designation station can receive confirmation that such commands were correctly received and have taken effect. Otherwise, the behavior of a station may be uncertain and transmissions to the station may need to be delayed or handled differently. Other conventional networks may use an encoded address label to address the intended recipients, but this may limit the number of addressable receivers.

It should be understood at the outset that although an illustrative implementation of one or more example embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence.

Disclosed herein are various example embodiments for selectively addressing receivers when communicating multi-destination data packets, frames, messages, or the like, and processing aggregate multi-destination data packets. Multi-destination packets include broadcast messages, intended to reach all stations on a link except the sender, and multicast messages, intended to reach a designated subset of stations on the link not including the sender. A multi-destination frame may be communicated to a plurality of receivers that may partially process the multi-destination frame to determine further processing instructions. The multi-destination frame may comprise a list of stations that may accept the transmission or a list of stations that may not accept the transmission. Additional information (e.g., tagging information) for one or more receivers may be encoded and/or communicated using the multi-destination frame. The amount of air time used to communicate with a plurality of receivers may be reduced by using such a multi-destination frame.

<FIG> is a schematic diagram of an example embodiment of a network system <NUM>. The network system <NUM> may generally comprise a network <NUM> coupled to a network <NUM>. The network <NUM> may be a wide area network (WAN) or a local area network (LAN). The network <NUM> may be a LAN. The data traffic may be communicated using wired and/or wireless links between the network <NUM> and the network <NUM>. The network <NUM> may comprises a transmitting node <NUM> and a plurality of receiving nodes 106A-<NUM>. In one example embodiment, the network <NUM> may be a wireless network configured to support wireless data communication between a transmitting node <NUM> and receiving nodes 106A-<NUM>. Specifically, the network <NUM> may be a Wi-Fi network, a radio network, a Bluetooth network, a zigbee network, or any other suitable radio based network as would be appreciated by one of ordinary skill in the art upon viewing this disclosure. In an example embodiment, network <NUM> may be an IEEE <NUM>. 11ak network. Additional information for an IEEE <NUM>. 11ak network may be as described in IEEE P802. <NUM> titled, ". Part <NUM>: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, Amendment. Enhancements For Transit Links Within Bridged Networks,".

The transmitting node <NUM> and the receiving nodes 106A-<NUM> may be any device or components that support the transportation of data traffic (e.g., data packets) through the network <NUM>. For example, the transmitting node <NUM> and the receiving nodes 106A-<NUM> may include a switch, a router, an AP, an AP station, a user-equipment, a mobile communications device, and any other suitable network device for communicating data packets as would be appreciated by one of ordinary skill in the art upon viewing this disclosure, or combinations thereof. The transmitting node <NUM> may be configured to receive data traffic (e.g., data packets) from the network <NUM> and/or a network node, to establish a wireless connection with one or more receiving nodes 106A-<NUM>, and to communicate data traffic with each of the receiving nodes 106A-<NUM>. The connection between the transmitting node <NUM> and a receiving node 106A-<NUM> may simulate a virtual port between the transmitter node <NUM> and one or more of the receiving nodes 106A-<NUM>. The data traffic may be communicated using wireless links between the transmitting node <NUM> and each of the receiving nodes 106A-<NUM>. In one example embodiment, the receiving nodes 106A-<NUM> may not be configured to communicate with other receiving nodes 106A-<NUM>. Alternatively, one or more of the receiving nodes 106A-<NUM> may be able to communicate with other receiving nodes 106A-<NUM>. In an example embodiment, the transmitting node <NUM> may be an IEEE <NUM>. 11ak AP and the receiving nodes 106A-<NUM> may comprise a combination of IEEE <NUM>. 11ak AP stations and non-<NUM>. 11ak AP stations. 11ak AP stations may not accept a multi-destination frame and may drop the frame. An AP that supports IEEE <NUM>. 11ak may implement IEEE <NUM>. 11ak when sending to IEEE <NUM>. 11ak AP stations that drop any non-<NUM>. 11ak multi-destination messages.

Using <FIG> as an example, the transmitting node <NUM> may receive data traffic from the network <NUM>. The transmitting node <NUM> may generate a multi-destination frame that comprises a list of receiving nodes 106A-<NUM> that may process the multi-destination frame and the data traffic. The transmitting node <NUM> may transmit the multi-destination frame to the receiving nodes 106A-<NUM>. The receiving nodes 106A-<NUM> may process (e.g., partially process) the multi-destination frame using the list of receiving nodes 106A-<NUM> to determine whether to further process the multi-destination frame or to discard the multi-destination frame.

As persons of ordinary skill in the art may appreciate, although <FIG> illustrates a network system <NUM> with that comprises a network <NUM>, a network <NUM>, a single transmitting node <NUM>, and a plurality of receiving nodes 106A-<NUM>, the disclosure is not limited to only this specific application. For instance, the network system <NUM> may comprise a plurality of networks, a plurality of transmitting nodes <NUM> and any suitable number of receiving nodes 106A-<NUM>. The transmitting node <NUM> and the receiving nodes 106A-<NUM> may be interconnected amongst each other to form a plurality of different network topologies. The use and discussion in <FIG> is only an example to facilitate ease of description and explanation. Furthermore, throughout the disclosure the term "multi-destination frame" and "aggregate frame" may be used interchangeably to describe a data frame that may address and comprise data content for a plurality of receiving nodes (e.g., receiving nodes 106A-<NUM>).

<FIG> is a schematic diagram of an example embodiment of a network element <NUM> that may be used to transport and process traffic through at least a portion of a network system <NUM> shown in <FIG>. At least some of the features/methods described in the disclosure may be implemented in a network element. For instance, the features/methods of the disclosure may be implemented in hardware, firmware, and/or software installed to run on the hardware. The network element <NUM> may be any device (e.g., an access point, an access point station, a server, a client, a user-equipment, a mobile communications device, etc.) that transports data through a network, system, and/or domain. Moreover, the terms network "element," network "node," network "component," network "module," and/or similar terms may be interchangeably used to generally describe a network device and do not have a particular or special meaning unless otherwise specifically stated and/or claimed within the disclosure. In one example embodiment, the network element <NUM> may be an apparatus configured to implement dynamic multi-destination addressing and/or to establish and communicate data traffic via a radio based connection (e.g., Wi-Fi). For example, network element <NUM> may be or incorporated within transmitting node <NUM> or a receiving node (e.g., receiving nodes 106A-<NUM>) as described in <FIG>.

The network element <NUM> may comprise one or more downstream ports <NUM> coupled to a transceiver (Tx/Rx) <NUM>, which may be transmitters, receivers, or combinations thereof. The Tx/Rx <NUM> may transmit and/or receive frames from other network nodes via the downstream ports <NUM>. Similarly, the network element <NUM> may comprise another Tx/Rx <NUM> coupled to a plurality of upstream ports <NUM>, wherein the Tx/Rx <NUM> may transmit and/or receive frames from other nodes via the upstream ports <NUM>. The downstream ports <NUM> and/or the upstream ports <NUM> may include electrical and/or optical transmitting and/or receiving components. In another example embodiment, the network element <NUM> may comprise one or more antennas coupled to the Tx/Rx <NUM>. The Tx/Rx <NUM> may transmit and/or receive data (e.g., packets) from other network elements wirelessly via one or more antennas.

A processor <NUM> may be coupled to the Tx/Rx <NUM> and may be configured to process the frames and/or determine which nodes to send (e.g., transmit) the packets. In an example embodiment, the processor <NUM> may comprise one or more multi-core processors and/or memory modules <NUM>, which may function as data stores, buffers, etc. The processor <NUM> may be implemented as a general processor or may be part of one or more application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or digital signal processors (DSPs). Although illustrated as a single processor, the processor <NUM> is not so limited and may comprise multiple processors. The processor <NUM> may be configured to communicate and/or process multi-destination frames.

<FIG> illustrates that a memory module <NUM> may be coupled to the processor <NUM> and may be a non-transitory medium configured to store various types of data. Memory module <NUM> may comprise memory devices including secondary storage, read-only memory (ROM), and random-access memory (RAM). The secondary storage is typically comprised of one or more disk drives, optical drives, solid-state drives (SSDs), and/or tape drives and is used for non-volatile storage of data and as an over-flow storage device if the RAM is not large enough to hold all working data. The secondary storage may be used to store programs that are loaded into the RAM when such programs are selected for execution. The ROM is used to store instructions and perhaps data that are read during program execution. The ROM is a non-volatile memory device that typically has a small memory capacity relative to the larger memory capacity of the secondary storage. The RAM is used to store volatile data and perhaps to store instructions. Access to both the ROM and RAM is typically faster than to the secondary storage.

The memory module <NUM> may be used to house the instructions for carrying out the various example embodiments described herein. In one example embodiment, the memory module <NUM> may comprise a dynamic multi-destination addressing module <NUM> that may be implemented on the processor <NUM>. In one example embodiment, the dynamic multi-destination addressing module <NUM> may be implemented on a transmitting node to generate and/or communicate an aggregate frame which selectively addresses a plurality of receiving nodes for a multi-destination data transmission. In another example embodiment, the dynamic multi-destination addressing module <NUM> may be implemented on a receiving node to process an aggregate frame.

It is understood that by programming and/or loading executable instructions onto the network element <NUM>, at least one of the processor <NUM>, the cache, and the long-term storage are changed, transforming the network element <NUM> in part into a particular machine or apparatus, for example, a multi-core forwarding architecture having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules known in the art. Decisions between implementing a concept in software versus hardware typically hinge on considerations of stability of the design and number of units to be produced rather than any issues involved in translating from the software domain to the hardware domain. Generally, a design that is still subject to frequent change may be preferred to be implemented in software, because re-spinning a hardware implementation is more expensive than re-spinning a software design. Generally, a design that is stable will be produced in large volume may be preferred to be implemented in hardware (e.g., in an ASIC) because for large production runs the hardware implementation may be less expensive than software implementations. Often a design may be developed and tested in a software form and then later transformed, by well-known design rules known in the art, to an equivalent hardware implementation in an ASIC that hardwires the instructions of the software. In the same manner as a machine controlled by a new ASIC is a particular machine or apparatus, likewise a computer that has been programmed and/or loaded with executable instructions may be viewed as a particular machine or apparatus.

Any processing of the present disclosure may be implemented by causing a processor (e.g., a general purpose multi-core processor) to execute a computer program. In this case, a computer program product can be provided to a computer or a network device using any type of non-transitory computer readable media. The computer program product may be stored in a non-transitory computer readable medium in the computer or the network device. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), compact disc read-only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-R/W), digital versatile disc (DVD), Blu-ray (registered trademark) disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), erasable PROM), flash ROM, and RAM). The computer program product may also be provided to a computer or a network device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.

<FIG> is a flowchart of an example embodiment of a dynamic multi-destination addressing method <NUM>. In an example embodiment, method <NUM> may be implemented on a receiver (e.g., receiver nodes 106A-<NUM> as described in <FIG>) that support IEEE <NUM>. 11ak to process a multi-destination frame (e.g., aggregate frame <NUM> as will be discussed in <FIG>). At step <NUM>, method <NUM> receives a multi-destination frame from a transmitting node (e.g., transmitting node <NUM>). At step <NUM>, method <NUM> processes a control block (e.g., control block <NUM> as will be discussed in <FIG>) of the multi-destination frame to determine a control block type. A control block type describes a relationship between a list of receivers and the data content within the multi-destination frame. Specifically, the control block type describes whether the receivers that are identified by the control block may accept or discard the multi-destination frame. A control block may be processed by parsing a control block header (e.g., control block header <NUM> as will be discussed in <FIG>) and/or a control block data (e.g., control block data <NUM> as will be discussed in <FIG>) to extract information.

At step <NUM>, method <NUM> may parse the control block header <NUM> and using information obtained from the control block header <NUM> may determine whether the control block type is an exclude list. The control block header <NUM> may comprise one or more fields (e.g., a flag field) that may indicate a control block type by using flag bits or numerical values associated with various control block types. If the control block type is an exclude list, then method <NUM> may proceed to step <NUM>, otherwise, method <NUM> may proceed to step <NUM>. At step <NUM>, method <NUM> may determine if the receiver is in the receiver list. Using <FIG> as an example, a receiver list may comprise receiving nodes 106A-106D and not include receiving nodes 106E-<NUM>. Alternatively, the receiving list may reference any number and/or combination of receiving nodes 106A-<NUM>. Method <NUM> may parse and extract information from the control block to determine if the receiver is identified in the receiver list (e.g., an association identifier (AID) item <NUM> as will be discussed in <FIG>) in the control block. If the receiver is in the receiver list, then method <NUM> may proceed to step <NUM>, otherwise, method <NUM> may proceed to step <NUM>. At step <NUM>, method <NUM> discards the multi-destination frame and terminates.

Returning to step <NUM>, if the receiver is not in the receiver list, then method <NUM> proceeds to step <NUM>. At step <NUM>, method <NUM> processes the multi-destination frame and terminates. Method <NUM> may process the multi-destination frame by extracting and/or using the one or more data frames within the multi-destination frames. The data content of the data frames may be stored, used, displayed, communicated to other network devices, any other operation as would be appreciated by one of ordinary skill in the art upon viewing this disclosure, or combinations thereof. Additionally, method <NUM> may parse and extract tagging information associated with the receiver. Method <NUM> may generate and/or communicate a data packet that comprises the tagging information and one or more of the data frames.

Returning to step <NUM>, if the control block type is not an exclude list (e.g., an include list), method <NUM> may proceed to step <NUM>. At step <NUM>, method <NUM> may parse and extract information from the control block to determine if the receiver is in the receiver list. Method <NUM> implements step <NUM> in a manner substantially similar to step <NUM>, as previously discussed. If the receiver is in the receiver list, then method <NUM> may proceed to step <NUM>, otherwise, method <NUM> may proceed to step <NUM>. At step <NUM>, method <NUM> processes the multi-destination frame and terminates. Method <NUM> implements step <NUM> in a manner substantially similar to step <NUM>, as previously discussed. Returning to step <NUM>, if the receiver is not in the receiver list, then method <NUM> discards the multi-destination frame and terminates.

<FIG> is a flowchart of another example embodiment of a dynamic multi-destination addressing method <NUM>. In an example embodiment, method <NUM> may be implemented on a transmitter (e.g., a transmitting node <NUM> as described in <FIG>) to selectively address receivers when communicating multi-destination data packets. At step <NUM>, method <NUM> may obtain one or more data frames. Method <NUM> may generate and/or receive one or more data frames to communicate to one or more receivers. The data frames may carry data content for the one or more receivers. At step <NUM>, method <NUM> may indicate a control block type in a control block header. Method <NUM> may set one or more flag bit or a numerical value in the control block headers (e.g., in a flag field) to indicate a desired control block type. Method <NUM> may generate and/or attach a control block to the data frames. In one example embodiment, the control block type may be configured as an include list. In another example embodiment, the control block type may be configured as an exclude list.

At step <NUM>, method <NUM> generates a receiver list associated with the control block type. Method <NUM> may generate a list, a table, or the like, that identifies one or more receivers. The receivers may each be identified by an AID, an Internet Protocol (IP) address, a Media Access Control (MAC) address, a tag, or any other suitable identifier as would be appreciated by one of ordinary skill in the art upon viewing this disclosure. Method <NUM> may generate and/or attach one or more AID items to the control block and data frames. The AID items may comprise a list of receivers that corresponds with receiver type list indicated by the control block. When the control block type is configured as an include list, the AID items may be a list of receivers that may process the received data packet. When the control block type is configured as an exclude list, the AID item may be a list of receivers that may discard the received data packet.

Optionally, at step <NUM>, method <NUM> may set additional parameters within a control block. Method <NUM> may set one or more additional parameters, such as indicating that tagging information is available. Method <NUM> may configure the data packet to provide the tagging information. The tagging information may be a VLAN identifier (VID), a priority indicator, or any other suitable tag as would be appreciated by one of ordinary skill in the art upon viewing this disclosure. Method <NUM> may provide a default tag and/or other tags. One or more flag bits may be set to indicate tagging instructions. At step <NUM>, method <NUM> may generate an aggregate frame header. Method <NUM> may generate and/or attach an aggregate header to the AID items, the control block, and the data frames, and thereby generate a multi-destination frame. At step <NUM>, method <NUM> sends the multi-destination frame that comprises the aggregate header, the AID items, the control block, and the data frames to a plurality of receivers.

<FIG> is a schematic diagram of an example embodiment of a multi-destination frame <NUM>. The multi-destination frame <NUM> may be a data frame and may generally comprise a header <NUM>, one or more control blocks <NUM>, and data <NUM>. The header <NUM> may indicate that the data packet is a multi-destination (e.g., multicast) frame. A receiving node (e.g., a legacy receiver) that is not configured to support the control block, an exclude or include receiver list, header <NUM>, and/or the multi-destination frame <NUM> may discard packets that comprise the header <NUM> without further processing of the multi-destination frame <NUM>. The control block <NUM> may comprise instructions or information for processing (e.g., further processing) the multi-destination frame <NUM>, such as a list of receivers that may process the multi-destination frame <NUM>, a list of receivers that may not process the multi-destination frame <NUM>, one or more receiver identifiers, and tagging information. The data <NUM> may comprise data content or a payload. Alternatively, in an aggregated data frame the data may comprise one or more data frames comprising data content or a payload for a plurality of receiving nodes (e.g., receiving node 106A-<NUM>). The aggregated data frame embodiment will be discussed in more detail in <FIG>.

<FIG> is a schematic diagram of another example embodiment of a multi-destination frame <NUM>. The multi-destination frame <NUM> may be an aggregate data frame (e.g., a media access control (MAC) service data unit (MSDU), an aggregated-MSDU (A-MSDU), a MAC protocol data unit (MPDU), an aggregate-MPDU (A-MPDU), or an IEEE <NUM>. 11ak frame) and may generally comprise a header <NUM>, one or more control blocks <NUM>, and a plurality of data <NUM>. The header <NUM> and/or the control block <NUM> may be similar to header <NUM> and control block <NUM> as discussed in <FIG>. The data <NUM> may comprise a plurality of data frames comprising data content or a payload for a plurality of receiving nodes (e.g., receiving node 106A-<NUM>).

<FIG> is a schematic diagram of an example embodiment of a control block <NUM>. In an example embodiment, the control block <NUM> may comprise a control block header <NUM> and a control block data <NUM> appearing in an aggregate frame. The control block header <NUM> may comprise a length field <NUM>, a flags field <NUM>, a default size (DTsize) field <NUM>, and a default tag (DefTag) field <NUM>. The length field <NUM> may be about <NUM> bits and may indicate the length (e.g., in bytes) of control block <NUM>. The flags field <NUM> may be about <NUM> bits and may indicate a control block type. The control block type may be a sub-setting exclusion list (e.g., an exclude list), a sub-setting inclusion list (e.g., an include list), sub-setting inclusion with prefix data list, or a vendor specific list. An include list may indicate that a corresponding list of receivers may process a multi-destination frame (e.g., multi-destination frame <NUM> in <FIG>). An exclude list may indicate that a corresponding list of receivers may discard the multi-destination frame. A sub-setting inclusion with prefix data list may indicate that a corresponding list of receivers may process a multi-destination frame using prefix data (e.g., tagging information). A vendor specific type may indicate any control information used to process the multi-destination frame. In an example embodiment, one of the flag bits (e.g., the top bit) in the flags field <NUM> may be a first value (e.g., set to zero) and may indicate the control block type is an include list. Alternatively, the flag bit (e.g., the top bit) in the flags field <NUM> may be a second value (e.g., set to one) and may indicate the control block type is an exclude list. The DTsize field <NUM> may be about eight bits and may indicate the size (e.g., in bytes) of the DefTag field <NUM>. The DefTag field <NUM> may be about <NUM> bits and may indicate a default tag that may be used when tagging information is unavailable. The control block data <NUM> may comprise one or more AID items <NUM>. An AID item <NUM> may be a block that comprises one or more entries about <NUM> bits in length and may identify a receiver and/or a peering relationship between a sender and the receiver.

In another example embodiment, the control block <NUM> may comprise a control block header field, a control block data field, and a padding field. The control block header field may be about two octets and may comprise a "more control block" field, a control block type field, and a control block data length field. The "more control block" field may be a one bit flag and may indicate the presence of additional control blocks when a multi-destination frame (e.g., an aggregate multi-destination frame) comprises a plurality of control blocks. For example, the "more control block" field may be a first value (e.g., set to zero) to indicate that the control block is the last control block and may be a second value (e.g., set to one) to indicate that the control block is followed by another control block. The control block type may be about five bits and may indicate the control block type (e.g., sub-setting exclusion, sub-setting inclusion, sub-setting inclusion with prefix data, or vendor specific). The control block data length field may be about ten bits and may indicate the length (e.g., in bytes) of the control block data field. The control block data field may be up to <NUM> octets and may contain data content (e.g., AID items <NUM>). The padding field may be up to about three octets and may pad the control block to such that the length of every control block is a multiple of four octets.

Claim 1:
A method performed by a transmitting node (<NUM>) for processing a multi-destination frame (<NUM>, <NUM>) in a network (<NUM>), the method comprising:
generating a multi-destination frame (<NUM>, <NUM>) that comprises a control block type, a receiver list that identifies multiple receivers, and a data payload, wherein the control block type is used to indicate:
the multiple receivers to accept the multi-destination frame (<NUM>, <NUM>) without discarding the multi-destination frame (<NUM>, <NUM>); or
the multiple receivers to process the multi-destination frame (<NUM>, <NUM>) by discarding the multi-destination frame (<NUM>, <NUM>);
sending the multi-destination frame (<NUM>, <NUM>) to a receiving node (106A-<NUM>) using a wireless radio link.