WO2020118203A2

WO2020118203A2 - Multicast flow control in rlnc-based data transmission

Info

Publication number: WO2020118203A2
Application number: PCT/US2019/064981
Authority: WO
Inventors: Sung-Yeon Kim; Dirk Trossen TROSSEN
Original assignee: Idac Holdings, Inc.
Priority date: 2018-12-07
Filing date: 2019-12-06
Publication date: 2020-06-11
Also published as: WO2020118203A3

Abstract

A method for transmitting Random Linear Network Coding (RLNC) data. The method comprises: transmitting first RLNC data to a plurality of receiving devices using a first transmission rate; receiving a first feedback for the first RLNC data from each of the plurality of receiving devices; determining whether a first condition has been satisfied by the received first feedbacks, wherein on a condition that the first condition has been satisfied, dividing the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of receiving devices, retransmitting a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices.

Description

MULTICAST FLOW CONTROL IN RLNC-BASED DATA TRANSMISSION

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application No. 62/776,873, filed on December, 7, 2019, the contents of which are incorporated herein by reference.

BACKGROUND

[0002] In Mobile Edge Computing (MEC) Flexible IP-based Services (FLIPS) is an operator- based MEC application that may accelerate delivery of Internet Protocol (IP) content, such as streaming media. FLIPS may utilize software-defined networking (SDN) and network function virtualization (NFV) approaches to deliver content. In such a system, there may be a need to control and implement protocols for the flow of content when delivering to more than one receiver.

SUMMARY

[0003] A method for transmitting Random Linear Network Coding (RLNC) data. The method comprises: transmitting first RLNC data to a plurality of receiving devices using a first transmission rate; receiving a first feedback for the first RLNC data from each of the plurality of receiving devices; determining whether a first condition has been satisfied by the received first feedbacks, wherein on a condition that the first condition has been satisfied, dividing the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of receiving devices, retransmitting a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices

[0004] A base station used for transmitting Random Linear Network Coding (RLNC) data. The base station comprises: a transmitter configured to transmit first RLNC data to a plurality of receiving devices using a first transmission rate; a receiver configured to receive a first feedback for the first RLNC data from each of the plurality of receiving devices; a processor configured to determine whether a first condition has been satisfied by the received first feedbacks, wherein on a condition that the first condition has been satisfied, the processor is further configured to divide the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of WTRUs, the transmitter is further configured to retransmit a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Furthermore, like reference numerals in the figures indicate like elements, and wherein:

[0006] FIG. 1A is a system diagram illustrating an example communications system in which one or more disclosed embodiments may be implemented;

[0007] FIG. 1 B is a system diagram illustrating an example wireless transmit/receive unit (WTRU) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0008] FIG. 1 C is a system diagram illustrating an example radio access network (RAN) and an example core network (CN) that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0009] FIG. 1 D is a system diagram illustrating a further example RAN and a further example CN that may be used within the communications system illustrated in FIG. 1A according to an embodiment;

[0010] FIG. 2 illustrates an example of edge termination points (ETPs) communication;

[001 1] FIG. 3 illustrates an example of transaction to flow mapping;

[0012] FIG. 4 illustrates an example of data packets and redundancies;

[0013] FIG. 5A is a flow chart illustrating an embodiment of the method for multicast flow control in Random Linear Network Coding (RLNC) data transmission according to an embodiment of this application;

[0014] FIG. 5B is a flow chart illustrating a method for multicast flow control in RLNC data transmission according to another embodiment of this application;

[0015] FIG. 5C is a flow chart illustrating a method for multicast flow control in RLNC data transmission according to another embodiment of this application;

[0016] FIG. 5D is a flow chart illustrating a method for multicast flow control in RLNC data transmission according to another embodiment of this application;

[0017] FIG. 6A is an schematic operational flow chart illustrating a method for multicast flow control in RLNC data transmission according to an embodiment of this application;

[0018] FIG. 6B is an schematic operational flow chart illustrating a method for multicast flow control in RLNC data transmission according to another embodiment of this application; [0019] FIG. 7 is an operational flow chart schematically illustrating a method for receiving RLNC data according to an embodiment of this application;

[0020] FIG. 8 illustrates a state machine of a sender;

[0021] FIG. 9 illustrates a state machine of a receiver;

[0022] FIG. 10 illustrates a packet format and field types for a data packet;

[0023] FIG. 1 1 illustrates a packet format and field types for a NACK packet;

[0024] FIG. 12 illustrates an example of an end-to-edge flow control; and

[0025] FIG. 13 illustrates an example of an edge-to-edge flow control.

DETAILED DESCRIPTION

[0026] FIG. 1A is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments may be implemented. The communications system 100 may be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA (SC-FDMA), zero-tail unique-word discrete Fourier transform Spread OFDM (ZT-UW-DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0027] As shown in FIG. 1A, the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104, a core network (ON) 106, a public switched telephone network (PSTN) 108, the Internet 1 10, and other networks 1 12, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and/or network elements. Each of the WTRUs 102a, 102b, 102c, 102d may be any type of device configured to operate and/or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, any of which may be referred to as a station (STA), may be configured to transmit and/or receive wireless signals and may include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. Any of the WTRUs 102a, 102b, 102c and 102d may be interchangeably referred to as a UE.

[0028] The communications systems 100 may also include a base station 114a and/or a base station 1 14b. Each of the base stations 1 14a, 1 14b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks, such as the CN 106, the Internet 1 10, and/or the other networks 112. By way of example, the base stations 1 14a, 1 14b may be a base transceiver station (BTS), a NodeB, an eNode B (eNB), a Home Node B, a Home eNode B, a next generation NodeB, such as a gNode B (gNB), a new radio (NR) NodeB, a site controller, an access point (AP), a wireless router, and the like. While the base stations 1 14a, 1 14b are each depicted as a single element, it will be appreciated that the base stations 1 14a, 114b may include any number of interconnected base stations and/or network elements.

[0029] The base station 114a may be part of the RAN 104, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, and the like. The base station 1 14a and/or the base station 1 14b may be configured to transmit and/or receive wireless signals on one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a wireless service to a specific geographical area that may be relatively fixed or that may change over time. The cell may further be divided into cell sectors. For example, the cell associated with the base station 1 14a may be divided into three sectors. Thus, in one embodiment, the base station 1 14a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 1 14a may employ multiple-input multiple output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and/or receive signals in desired spatial directions.

[0030] The base stations 1 14a, 1 14b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 1 16, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 1 16 may be established using any suitable radio access technology (RAT). [0031] More specifically, as noted above, the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 1 14a in the RAN 104 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 116 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (FISPA+). HSPA may include High-Speed Downlink (DL) Packet Access (FISDPA) and/or High-Speed Uplink (UL) Packet Access (HSUPA).

[0032] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 1 16 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A) and/or LTE-Advanced Pro (LTE-A Pro).

[0033] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement a radio technology such as NR Radio Access , which may establish the air interface 1 16 using NR.

[0034] In an embodiment, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement multiple radio access technologies. For example, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement LTE radio access and NR radio access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c may be characterized by multiple types of radio access technologies and/or transmissions sent to/from multiple types of base stations (e.g., an eNB and a gNB).

[0035] In other embodiments, the base station 1 14a and the WTRUs 102a, 102b, 102c may implement radio technologies such as IEEE 802.11 (i.e., Wireless Fidelity (WiFi), IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.

[0036] The base station 1 14b in FIG. 1 A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a campus, an industrial facility, an air corridor (e.g., for use by drones), a roadway, and the like. In one embodiment, the base station 114b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.1 1 to establish a wireless local area network (WLAN). In an embodiment, the base station 1 14b and the WTRUs 102c, 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 1 14b and the WTRUs 102c, 102d may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR etc.) to establish a picocell or femtocell. As shown in FIG. 1A, the base station 1 14b may have a direct connection to the Internet 1 10. Thus, the base station 1 14b may not be required to access the Internet 1 10 via the CN 106.

[0037] The RAN 104 may be in communication with the CN 106, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data may have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 may provide call control, billing services, mobile location- based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high- level security functions, such as user authentication. Although not shown in FIG. 1A, it will be appreciated that the RAN 104 and/or the CN 106 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which may be utilizing a NR radio technology, the CN 106 may also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0038] The CN 106 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and/or the other networks 1 12. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 1 10 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and/or the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 1 12 may include wired and/or wireless communications networks owned and/or operated by other service providers. For example, the networks 1 12 may include another CN connected to one or more RANs, which may employ the same RAT as the RAN 104 or a different RAT.

[0039] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communications system 100 may include multi-mode capabilities (e.g., the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks over different wireless links). For example, the WTRU 102c shown in FIG. 1A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 1 14b, which may employ an IEEE 802 radio technology.

[0040] FIG. 1 B is a system diagram illustrating an example WTRU 102. As shown in FIG. 1 B, the WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and/or other peripherals 138, among others. It will be appreciated that the WTRU 102 may include any subcombination of the foregoing elements while remaining consistent with an embodiment.

[0041] The processor 1 18 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 1 18 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 1 18 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 1 B depicts the processor 1 18 and the transceiver 120 as separate components, it will be appreciated that the processor 1 18 and the transceiver 120 may be integrated together in an electronic package or chip.

[0042] The transmit/receive element 122 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 1 14a) over the air interface 1 16. For example, in one embodiment, the transmit/receive element 122 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 122 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit/receive element 122 may be configured to transmit and/or receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit and/or receive any combination of wireless signals.

[0043] Although the transmit/receive element 122 is depicted in FIG. 1 B as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 1 16.

[0044] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.1 1 , for example.

[0045] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 1 18 may also output user data to the speaker/microphone 124, the keypad 126, and/or the display/touchpad 128. In addition, the processor 1 18 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 130 and/or the removable memory 132. The non-removable memory 130 may include random-access memory (RAM), readonly memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 1 18 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0046] The processor 1 18 may receive power from the power source 134, and may be configured to distribute and/or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.

[0047] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 1 16 from a base station (e.g., base stations 1 14a, 1 14b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0048] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs and/or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a Virtual Reality and/or Augmented Reality (VR/AR) device, an activity tracker, and the like. The peripherals 138 may include one or more sensors. The sensors may be one or more of a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor, an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor and the like.

[0049] The WTRU 102 may include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for both the UL (e.g., for transmission) and DL (e.g., for reception) may be concurrent and/or simultaneous. The full duplex radio may include an interference management unit to reduce and or substantially eliminate selfinterference via either hardware (e.g., a choke) or signal processing via a processor (e.g., a separate processor (not shown) or via processor 1 18). In an embodiment, the WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for either the UL (e.g., for transmission) or the DL (e.g., for reception)).

[0050] FIG. 1 C is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 may also be in communication with the CN 106.

[0051] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 1 16. In one embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a.

[0052] Each of the eNode-Bs 160a, 160b, 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, and the like. As shown in FIG. 1 C, the eNode-Bs 160a, 160b, 160c may communicate with one another over an X2 interface.

[0053] The CN 106 shown in FIG. 1 C may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (PGW) 166. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0054] The MME 162 may be connected to each of the eNode-Bs 162a, 162b, 162c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM and/or WCDMA.

[0055] The SGW 164 may be connected to each of the eNode Bs 160a, 160b, 160c in the RAN 104 via the S1 interface. The SGW 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, 102c. The SGW 164 may perform other functions, such as anchoring user planes during inter-eNode B handovers, triggering paging when DL data is available for the WTRUs 102a, 102b, 102c, managing and storing contexts of the WTRUs 102a, 102b, 102c, and the like.

[0056] The SGW 164 may be connected to the PGW 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0057] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which may include other wired and/or wireless networks that are owned and/or operated by other service providers.

[0058] Although the WTRU is described in FIGS. 1 A-1 D as a wireless terminal, it is contemplated that in certain representative embodiments that such a terminal may use (e.g., temporarily or permanently) wired communication interfaces with the communication network.

[0059] In representative embodiments, the other network 1 12 may be a WLAN.

[0060] A WLAN in Infrastructure Basic Service Set (BSS) mode may have an Access Point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a Distribution System (DS) or another type of wired/wireless network that carries traffic in to and/or out of the BSS. Traffic to STAs that originates from outside the BSS may arrive through the AP and may be delivered to the STAs. Traffic originating from STAs to destinations outside the BSS may be sent to the AP to be delivered to respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send traffic to the AP and the AP may deliver the traffic to the destination STA. The traffic between STAs within a BSS may be considered and/or referred to as peer-to-peer traffic. The peer-to-peer traffic may be sent between (e.g., directly between) the source and destination STAs with a direct link setup (DLS). In certain representative embodiments, the DLS may use an 802.1 1 e DLS or an 802.11 z tunneled DLS (TDLS). A WLAN using an Independent BSS (IBSS) mode may not have an AP, and the STAs (e.g., all of the STAs) within or using the IBSS may communicate directly with each other. The IBSS mode of communication may sometimes be referred to herein as an“ad-hoc” mode of communication.

[0061] When using the 802.1 1 ac infrastructure mode of operation or a similar mode of operations, the AP may transmit a beacon on a fixed channel, such as a primary channel. The primary channel may be a fixed width (e.g., 20 MHz wide bandwidth) or a dynamically set width. The primary channel may be the operating channel of the BSS and may be used by the STAs to establish a connection with the AP. In certain representative embodiments, Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) may be implemented, for example in 802.11 systems. For CSMA/CA, the STAs (e.g., every STA), including the AP, may sense the primary channel. If the primary channel is sensed/detected and/or determined to be busy by a particular STA, the particular STA may back off. One STA (e.g., only one station) may transmit at any given time in a given BSS.

[0062] High Throughput (HT) STAs may use a 40 MHz wide channel for communication, for example, via a combination of the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0063] Very High Throughput (VHT) STAs may support 20MHz, 40 MHz, 80 MHz, and/or 160 MHz wide channels. The 40 MHz, and/or 80 MHz, channels may be formed by combining contiguous 20 MHz channels. A 160 MHz channel may be formed by combining 8 contiguous 20 MHz channels, or by combining two non-contiguous 80 MHz channels, which may be referred to as an 80+80 configuration. For the 80+80 configuration, the data, after channel encoding, may be passed through a segment parser that may divide the data into two streams. Inverse Fast Fourier Transform (IFFT) processing, and time domain processing, may be done on each stream separately. The streams may be mapped on to the two 80 MHz channels, and the data may be transmitted by a transmitting STA. At the receiver of the receiving STA, the above described operation for the 80+80 configuration may be reversed, and the combined data may be sent to the Medium Access Control (MAC). [0064] Sub 1 GHz modes of operation are supported by 802.1 1 af and 802.1 1 ah. The channel operating bandwidths, and carriers, are reduced in 802.11 af and 802.1 1 ah relative to those used in 802.1 1 h, and 802.1 1 ac. 802.11 af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV White Space (TVWS) spectrum, and 802.1 1 ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.1 1 ah may support Meter Type Control/Machine-Type Communications (MTC), such as MTC devices in a macro coverage area. MTC devices may have certain capabilities, for example, limited capabilities including support for (e.g., only support for) certain and/or limited bandwidths. The MTC devices may include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0065] WLAN systems, which may support multiple channels, and channel bandwidths, such as 802.1 1 h, 802.1 1 ac, 802.1 1 af, and 802.1 1 ah, include a channel which may be designated as the primary channel. The primary channel may have a bandwidth equal to the largest common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and/or limited by a STA, from among all STAs in operating in a BSS, which supports the smallest bandwidth operating mode. In the example of 802.11 ah, the primary channel may be 1 MHz wide for STAs (e.g., MTC type devices) that support (e.g., only support) a 1 MHz mode, even if the AP, and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and/or other channel bandwidth operating modes. Carrier sensing and/or Network Allocation Vector (NAV) settings may depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which supports only a 1 MHz operating mode) transmitting to the AP, all available frequency bands may be considered busy even though a majority of the available frequency bands remains idle.

[0066] In the United States, the available frequency bands, which may be used by 802.1 1 ah, are from 902 MHz to 928 MHz. In Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 916.5 MHz to 927.5 MHz. The total bandwidth available for 802.1 1 ah is 6 MHz to 26 MHz depending on the country code.

[0067] FIG. 1 D is a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As noted above, the RAN 104 may employ an NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 1 16. The RAN 104 may also be in communication with the CN 106.

[0068] The RAN 104 may include gNBs 180a, 180b, 180c, though it will be appreciated that the RAN 104 may include any number of gNBs while remaining consistent with an embodiment. The gNBs 180a, 180b, 180c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the gNBs 180a, 180b, 180c may implement MIMO technology. For example, gNBs 180a, 108b may utilize beamforming to transmit signals to and/or receive signals from the gNBs 180a, 180b, 180c. Thus, the gNB 180a, for example, may use multiple antennas to transmit wireless signals to, and/or receive wireless signals from, the WTRU 102a. In an embodiment, the gNBs 180a, 180b, 180c may implement carrier aggregation technology. For example, the gNB 180a may transmit multiple component carriers to the WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum while the remaining component carriers may be on licensed spectrum. In an embodiment, the gNBs 180a, 180b, 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNB 180a and gNB 180b (and/or gNB 180c).

[0069] The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using transmissions associated with a scalable numerology. For example, the OFDM symbol spacing and/or OFDM subcarrier spacing may vary for different transmissions, different cells, and/or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using subframe or transmission time intervals (TTIs) of various or scalable lengths (e.g., containing a varying number of OFDM symbols and/or lasting varying lengths of absolute time).

[0070] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and/or a non-standalone configuration. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c without also accessing other RANs (e.g., such as eNode-Bs 160a, 160b, 160c). In the standalone configuration, WTRUs 102a, 102b, 102c may utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, WTRUs 102a, 102b, 102c may communicate with gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration WTRUs 102a, 102b, 102c may communicate with/connect to gNBs 180a, 180b, 180c while also communicating with/connecting to another RAN such as eNode-Bs 160a, 160b, 160c. For example, WTRUs 102a, 102b, 102c may implement DC principles to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In the non-standalone configuration, eNode-Bs 160a, 160b, 160c may serve as a mobility anchor for WTRUs 102a, 102b, 102c and gNBs 180a, 180b, 180c may provide additional coverage and/or throughput for servicing WTRUs 102a, 102b, 102c.

[0071] Each of the gNBs 180a, 180b, 180c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and/or DL, support of network slicing, DC, interworking between NR and E-UTRA, routing of user plane data towards User Plane Function (UPF) 184a, 184b, routing of control plane information towards Access and Mobility Management Function (AMF) 182a, 182b and the like. As shown in FIG. 1 D, the gNBs 180a, 180b, 180c may communicate with one another over an Xn interface.

[0072] The CN 106 shown in FIG. 1 D may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and possibly a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements may be owned and/or operated by an entity other than the CN operator.

[0073] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and may serve as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol data unit (PDU) sessions with different requirements), selecting a particular SMF 183a, 183b, management of the registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. Network slicing may be used by the AMF 182a, 182b in order to customize CN support for WTRUs 102a, 102b, 102c based on the types of services being utilized WTRUs 102a, 102b, 102c. For example, different network slices may be established for different use cases such as services relying on ultrareliable low latency (URLLC) access, services relying on enhanced massive mobile broadband (eMBB) access, services for MTC access, and the like. The AMF 182a, 182b may provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and/or non-3GPP access technologies such as WiFi.

[0074] The SMF 183a, 183b may be connected to an AMF 182a, 182b in the CN 106 via an N1 1 interface. The SMF 183a, 183b may also be connected to a UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type may be IP- based, non-IP based, Ethernet-based, and the like.

[0075] The UPF 184a, 184b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N3 interface, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 1 10, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices. The UPF 184, 184b may perform other functions, such as routing and forwarding packets, enforcing user plane policies, supporting multihomed PDU sessions, handling user plane QoS, buffering DL packets, providing mobility anchoring, and the like.

[0076] The CN 106 may facilitate communications with other networks. For example, the CN 106 may include, or may communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to the other networks 1 12, which may include other wired and/or wireless networks that are owned and/or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c may be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface to the UPF 184a, 184b and an N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0077] In view of FIGs. 1 A-1 D, and the corresponding description of FIGs. 1 A-1 D, one or more, or all, of the functions described herein with regard to one or more of: WTRU 102a-d, Base Station 1 14a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and/or any other device(s) described herein, may be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, the emulation devices may be used to test other devices and/or to simulate network and/or WTRU functions.

[0078] The emulation devices may be designed to implement one or more tests of other devices in a lab environment and/or in an operator network environment. For example, the one or more emulation devices may perform the one or more, or all, functions while being fully or partially implemented and/or deployed as part of a wired and/or wireless communication network in order to test other devices within the communication network. The one or more emulation devices may perform the one or more, or all, functions while being temporarily implemented/deployed as part of a wired and/or wireless communication network. The emulation device may be directly coupled to another device for purposes of testing and/or performing testing using over-the-air wireless communications.

[0079] The one or more emulation devices may perform the one or more, including all, functions while not being implemented/deployed as part of a wired and/or wireless communication network. For example, the emulation devices may be utilized in a testing scenario in a testing laboratory and/or a non-deployed (e.g., testing) wired and/or wireless communication network in order to implement testing of one or more components. The one or more emulation devices may be test equipment. Direct RF coupling and/or wireless communications via RF circuitry (e.g., which may include one or more antennas) may be used by the emulation devices to transmit and/or receive data.

[0080] In one or more embodiments there may be multicast flow control utilizing random linear network coding (RLNC) based data transmission between edge termination points (ETPs). Flow control between ETPs may augment the mapping from IP transactions to ETP transactions and the end-to-end flow control regime.

[0081] One or more embodiments concerning multicast flow control may be based on a congestion window over all the data whose reception has not yet been explicitly confirmed. For example, a base station may transmit data to multiple WTRUs with a transmission rate. The transmission rate may be controlled by adapting a size of the congestion window. The data within the congestion window may be encoded through RLNC, reducing the needed feedback to a single negative acknowledgement (NACK) at the very end of the congestion window with the possibility for loss recovery through added redundancy data. Specific consideration may be given in the transmission to a single unicast receiver as well as an ad-hoc created multicast group of receivers to support IP/HTTP-over-ICN solutions.

[0082] One or more embodiments concerning the multicast flow control according to this application may contain a window-based transmission rate adaptation and RLNC-based sequential data transmission including redundancies generation and missing data retransmission. For example, if a network for data transmission is congested or a receiver’s buffer runs over, the transmission rate may decrease, while the transmission rate increases if the network is not congested or there is a positive confirmation of reception for transmitted data. This strategy may be used in considering a multicast scenario. Hence, one or more embodiments described herein may address an efficient transmission rate adaptation protocol with consideration for multicast delivery. It will be appreciated that the RLNC-based data transmitted and the missing data retransmitted respectively comprise multiple data packets. Therefore, the terms“RLNC-based data” and“missing data” are used in this application may respectively refer to data packets comprised in them.

[0083] The RLNC-based data transmission may be applied to scenarios such as multicast and sequential data transmission. Hence, as described herein there may be a RLNC-based sequential data transmission and retransmission scheme.

[0084] One or more embodiments concerning multicast flow control may operate between ETPs (Edge Termination Points) (i.e., maintaining an ETP-to-ETP flow congestion window ( cwnd )). However, given the use of network coding, the congestion window may need to be aligned to the size of the IP transaction (i.e., the end-to-edge transaction delivered by any IP-based protocol such as HTTP, TCP or directly IP). Consequently, the cwnd value being used may be smaller than a current congestion window derived from the flow rate adjustments as discussed herein. This may ensure that the number of outstanding packets, defined through the cwnd, is never larger than one such IP transaction to avoid blocking of the cwnd data being sent to the application.

[0085] In one or more embodiments described herein, there may be systems, methods, and devices for RLNC-based sequential data transmission from a single sender across a group of one or more receivers. Further, there may be retransmission including RLNC-based retransmitted data packet and redundancies generation. The transmission rate control may include control for ad-hoc multicast flows. The congestion window may also be aligned to the size of the IP transaction being transported over the (possibly long-term) ETP-to-ETP flow through a virtual cwnd that is smaller or equal to the cwnd being used for flow control. There may be multicast group management that is aligned to an IP transaction being transported over the (possibly long-term) ETP-to-ETP flow.

[0086] In one or more embodiments there may be flow control technologies in a domain of systems like that of the FLIPS (Flexible IP Services) solution (i.e., systems that exhibit the capability for multicast delivery). The flow control technology as discussed herein may be developed to fit into the FLIPS solution or an equivalent solution. Since FLIPS utilizes path-based forwarding of packets, there may be specific characteristics for developing flow control. First, path-based forwarding may achieve instant multicast delivery by folding path information to several receivers into a single (multicast) path information. This may require flow control to expand from unicast to possibly (constantly varying) multicast relations. The current flow control in TCP may rely on point-to-point (unicast) relations and may therefore be unsuited for these techniques. Second, path-based forwarding may provide sequential data transmission, making the detection of lost packets an immediate task of receiving the next sequence number after a (sequence of) lost packet(s), which may be taken into account in one or more embodiments described herein.

[0087] FIG. 2 illustrates an example of termination points communication. A transport protocol for communication between ETPs may generally need to be a reliable transport protocol. Approaches discussed herein may realize a mapping of IP-based protocols onto the ETP-to-ETP protocol, while ensuring resource fairness by separating resource management between end-to-edge and edge-to- edge as depicted in FIG. 2.

[0088] In the transport protocol for communication between ETPs, resource management may terminate IP-based application flows at the edges, hence, the behavior of IP-based application flow control may no longer be visible in a layer 2 network. For this, there may be a protocol that introduces the approach of an IP transaction, which may be transferred as a unit of transfer over the (usually longer lived) ETP-to-ETP flow.

[0089] FIG. 3 illustrates an example of a transaction to flow mapping based on the transport protocol for communication between ETPs. Each (usually longer lived) ETP flow may realize its own error and flow control, while in certain cases, such as those defined through mapping HTTP transactions, the approach of a usually transient ad-hoc ETP flow may be introduced, which utilizes the least common denominator of all participating ETP flows. As discussed herein, there may be one or more embodiments that address the design for the flow and error control, both for long-lived ETP as well as transient as-hoc ETP flows.

[0090] Note, the ETP may be implemented as a stand-alone component at the edge of a network with the IP application residing in an IP-based device or the ETP may be integrated into a device where the processing of‘receiving’ an IP transaction, as in FIG. 3, is that of capturing the IP packet internally or utilizing modified IP protocol interfaces to the ETP that manifest the process of receiving the IP transaction. With this in mind, the‘sender’ and‘receiver’ of the ETP flow may always be the ETP, while its realization as either an edge or end device may depend on the aforementioned implementation choice. As discussed herein, a device may be a WTRU, base station, or the like.

[0091] Network coding is an emerging coding discipline that jointly improves network reliability and efficiency. Some communication networks may utilize source coding as a compression mechanism to reduce data redundancy and to reduce the resources necessary for data transportation over the network. Comparatively, some communication networks may utilize channel coding that adds redundancy for data transmission reliability over lossy channels. Network coding may add another layer of coding in-between source coding and channel coding. Of various network coding approaches, a random linear network coding (RLNC) may be an efficient network coding approach that enables network nodes to generate independently and randomly linear mappings of input to output data symbols over a finite field. Since the RLNC-based sequential data will be transmitted sequentially, the terms“RLNC-based sequential data” and“RLNC-based data” can be used interchangeably in this application.

[0092] It will be appreciated that in the following embodiments, those data transmitted by using the methods and/or the transmitting devices according to this application is RLNC-based data discussed above. The terms“RLNC-based data” and“RLNC data” can be used interchangeably.

[0093] It will also be appreciated that in the following embodiments, the methods according to this application can be used by ETPs to perform multicast flow control, and the ETPs can be implemented by either a base station or a WTRU shown in FIGs 1A-1 D . That is to say, a base station can use the methods according to this application to perform multicast flow control in RLNC data transmission, and a WTRU can also use the methods according to this application to perform multicast flow control in RLNC data transmission. In this application, unless otherwise indicated, a base station will be illustrated as an example of the transmitting devices according to this application, and a WTRU will be illustrated as an example of the receiving devices which may receive RLNC data from the transmitting devices.

[0094] In Transmission Control Protocol (TCP), any missing data may be retransmitted from the sender. RLNC data transmission may introduce redundancy generated using RLNC, and the missing data may be decoded and thus restored by using redundancies. The redundancies generation and the missing data retransmission will be further described below. While error control may be an important technique in flow control, the transmission rate adaptation may need to be defined since the network-level error may be mainly caused by network congestion.

[0095] However, while RLNC is a network coding technique that may simplify receiver’s decoding and allow for in-network recoding, thereby providing several possible extensions to error control in future extensions, the usage of RLNC data transmission as discussed herein may only be exemplary and not limiting to the general functioning of the protocol.

[0096] In one or more embodiments, RLNC data may be missing during its transmission because of network’s congestion. That is, a receiver may not receive all of those data transmitted from a sender. Therefore, the multicast flow control according to this application may also comprise missing data recovery scheme. This missing data recovery scheme may include redundancies transmission scheme and missing data retransmission scheme. Generally, the RLNC data may be transmitted with redundancies which may be used to restore missing data. If the missing data cannot be restored by the RLNC redundancies, then a retransmission will be requested and those missing data will be retransmitted. The RLNC redundancies transmission scheme will be described in detail with reference to FIG. 4 and specific embodiments below. The data retransmission scheme will be described in detail with reference to FIGs. 5A-5D and specific embodiments below.

[0097] One or more embodiments may relate to multicast flow control (e.g., multicast flow control method) in RLNC data transmission. The multicast flow control according to embodiments of this application may contain a window-based transmission rate adaptation and RLNC data transmission including redundancies generation and missing data retransmission. In other words, the multicast flow control according to this application comprises the following four elements: (1) a window-based transmission rate adaptation, (2) RLNC data transmission, (3) redundancies generation and (4) missing data retransmission. These four elements will be described in detail with reference to specific embodiments and examples below.

[0098] A method 500 shown in FIGs. 5A-5D for transmitting RLNC data from a sender to multiple receivers is an example of the multicast flow control according to this application. FIGs. 5A-5D illustrate operational flow charts for a sender to perform multicast flow control in RLNC data transmission. Before further describing the method 500, a sender and a receiver and a scenario where the multicast flow control may be applied will be first described as follows.

[0099] A sender according to embodiments of this application may be a base station shown in FIGs. 1A-1 D. The sender may transmit RLNC data through different wireless transmission technologies. For example, the sender may be a gNodeB applied in 5G NR. That is, the multicast flow control according to this application may be used by a based station in a scenario of 5G NR. The sender may also be eNodeB in LTE. That is, the multicast flow control according to this application may be used by a based station in a scenario of LTE. It will be appreciated that the above-mentioned 5G NR and LTE are only two exemplary scenarios where the multicast flow control according to this application may be applied. These two exemplary scenarios are not intended to be exclusive or be limiting to those embodiments of this application. The sender may also be any transmitting device which may transmit RLNC data, such as a based station and a WTRU. For the purpose of clear and definite description of the embodiments in this application, unless otherwise indicated, a base station which may be used in 5G NR will be taken as an example of the sender according to embodiments of this application. Therefore, the terms “transmitting device”,“sender” and“base station” may be used interchangeably.

[0100] A receiver according to embodiments of this application may be a WTRU shown in FIGs. 1A-1 D. The receiver may receive RLNC data transmitted from the base station and may transmit feedback (e.g., Negative-Acknowledgment, also known as NACK) to the base station. For example, the receiver may be a WTRU applied in a scenario of 5G NR, LTE, or any other wireless transmission technologies. It will be appreciated that the above description of the receiver is given by way of example, and it is not intended to be exclusive or be limiting to those embodiments of this application. The receiver may also be any receiving device which may receive RLNC data, such as a based station and a WTRU. For the purpose of clear and definite description of the embodiments in this application, unless otherwise indicated, a WTRU which may be used in 5G NR will be taken as an example of the receiver according to embodiments of this application. Therefore, the terms “receiving device”, “receiver” and“WTRU” may be used interchangeably. Since the multicast flow control according to this application may be applied to a scenario comprising multiple WTRUs, the multiple WTRUs may be referred to as a multicast group of WTRUs. [0101] It should be noted that RLNC data may not be transmitted once and for all, and typically multicast flow control requires RLNC data to be transmitted continually. Therefore, the method 500 according to this application may be performed cyclically for the purpose of multicast flow control. FIGs. 5A-5D will be focusing on micro-level description of different processes included in the multicast flow control method according to this application. FIGs. 6A-6B will be focusing on macrolevel description of the multicast flow control method from a cyclical performance perspective.

[0102] The method 500 will be described in detail with reference to FIGs. 5A-5D. FIG. 5A is a flow chart illustrating an embodiment of the method 500. Three preferable embodiments of the method 500 will be respectively illustrated through FIGs. 5B-5D. It will be appreciated that those three preferable embodiments also include those processes shown in FIG. 5A. Therefore, for the purpose of clear and definite description of the embodiments in this application, those processes shown in FIG. 5A will be omitted from FIGs. 5B-5D.

[0103] As shown in FIGs. 5A, the method 500 comprises: at 501 , transmitting first RLNC data to multiple receiving devices using a first transmission rate; at 502, receiving a first feedback for the first RLNC data from each of the multiple receiving devices; at 503, determining whether a first condition has been satisfied by the received first feedbacks, wherein on a condition that the first condition has been satisfied, at 504, dividing the multiple receiving devices into a first non- congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of receiving devices, at 505, retransmitting, using a second transmission rate less than the first transmission rate, a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices, and for the first non-congested group of receiving devices, at 506, transmitting, using a third transmission rate greater than the first transmission rate, second RLNC data to each receiving device in the first non-congested group of receiving devices.

[0104] Accordingly, a transmitting device according to this application for transmitting RLNC data may comprise: a transmitter configured to transmit first RLNC data to a plurality of receiving devices using a first transmission rate; a receiver configured to receive a first feedback for the first RLNC data from each of the plurality of receiving devices; a processor configured to determine whether a first condition has been satisfied by the received first feedbacks, wherein on a condition that the first condition has been satisfied, the processor is further configured to divide the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of WTRUs, the transmitter is further configured to retransmit, using a second transmission rate less than the first transmission rate, a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices, and for the first non-congested group of receiving devices, the transmitter is further configured to transmit, using a third transmission rate greater than the first transmission rate, second RLNC data to each receiving device in the first non-congested group of receiving devices.

[0105] The method 500 shown in FIG. 5A and the transmitting device according to this application will be described in detail as follows.

[0106] At 501 , the method 500 comprises transmitting first RLNC data to multiple receiving devices with a first transmission rate. That is, at 501 , the transmitter may be configured to transmit first RLNC data to multiple receiving devices using a first transmission rate.

[0107] The first RLNC data is data to be sent by the transmitting device (e.g., the base station) to the multiple receiving devices (e.g., WTRUs). For example, the first RLNC data may be generated by the base station by itself. That is, before the RLNC data transmission, the base station may perform the RLNC as discussed above to code source data, thereby generating the first RLNC data. The base station may also obtain the first RLNC data from a data source outside the base station. There is no limit in this application regarding the data source of RLNC data (including the first RLNC data and other RLNC data described below) as long as it can be obtained and transmitted by the transmitting device for the purpose of this application.

[0108] It will be appreciated that the term“first RLNC data” is intended to differentiate it from other RLNC data which may also be transmitted by the transmitting device in the following processes. Therefore, the term“first” here is not intended to be limiting to the content of the RLNC data to be transmitted by the transmitter at 501.

[0109] The first transmission rate is an initial transmission rate for the transmitting device to do RLNC data transmission. Transmission rate of RLNC data transmission may be determined through window-based transmission rate adaptation. To be more specific, the window-based transmission rate adaptation may represent a congestion window of all the data whose reception has not yet been explicitly confirmed by the receiving devices (e.g., WTRUs). Hence, the transmission rate may be controlled by adapting a congestion window size of RLNC data transmission. The larger the congestion window size, the greater the transmission rate, and vice versa.

[01 10] For example, if the network for data transmission is congested or a WTRU’s buffer runs over, then the base station may decrease the congestion window in order to make sure more data to be successfully received by WTRUs, and thus the transmission rate may decrease. If the network for data transmission is not congested or there is a positive confirmation of reception for transmitted data, then the base station may increase the congestion window size in order to obtain a greater data transmission capacity, and thus the transmission rate may increase. This strategy may be adapted in considering a scenario of ‘ad-hoc multicast’ (i.e., where data is being sent to more than one WTRU) since a network condition or a receiver’s buffer status may be different among multiple WTRUs. Hence, in one or more embodiments there may be one or more transmission rate adaptation protocol(s) with consideration for multicast delivery.

[01 1 1] In an embodiment, the first transmission rate is determined based on a first congestion window of the first RLNC data transmission. The first congestion window of the first RLNC data transmission may be determined by a system outside the base station or a user. The first congestion window may also be determined by the base station based on an algorithm prestored in the base station. It will be appreciated that the above exemplary ways of determining the first congestion window are not intended to be exclusive or be limiting to the present application. The first congestion window may be determined by any appropriate way as long as it can help to obtain the principle of the present application. It will also be appreciated that the term“first congestion window” is intended to differentiate it from other congestion windows which will be used by the base station to determine transmission rate in the future. Therefore, the term“first” here is not intended to be limiting to the congestion window used by the base station at 501.

[01 12] In an embodiment, the first transmission rate may be determined by the following equation (1):

cwnd = m + r Equation 1

[01 13] Here, m represents the number of data packets of RLNC data to be transmitted by the based station at 501. r represents data redundancies with RLNC data. According to the equation (1), a congestion window (i.e., cwnd) may be the sum of m and r . Since a RLNC data transmission rate may be controlled by adjusting a congestion window, the transmission rate (e.g., the first transmission rate at 501) used by the method 500 may also be determined by the above equation (1).

[01 14] It will be appreciated that the term“first transmission rate” is intended to differentiate it from other transmission rates which will be used for transmitting other RLNC data in the following processes. Therefore, the term“first” here is not intended to be limiting to the transmission rate for the transmitting device to transmit the first RLNC data at 501. Similarly, in the following embodiments, such terms like“second transmission rate” and“third transmission rate” may be used for similar purposes (e.g., for describing a transmission rate used for transmitting RLNC data) and they are intended to differentiate from each other. It will be appreciated that unless otherwise indicated, those transmission rates (e.g., the second transmission rate and the third transmission rate) may be determined through the same way as that discussed above for determining the first transmission rate.

[01 15] In an embodiment, the first congestion window may be aligned to a size of a first IP transaction being transported over Edge Termination Point (ETP)-to ETP flow. In an embodiment, the second congestion window may be aligned to a size of a second IP transaction being transported over ETP-to-ETP flow.

[01 16] The redundancies generation and the missing data retransmission will be described in more detail as follows. At 501 , the transmitting device may transmit the first RLNC data using first RLNC redundancies. RLNC data transmission may provide RLNC redundancies which may be used to restore missing data and a retransmission scheme for missing data that may not be restored by using the redundancies. Since the redundancies are RLNC-based generated, receiving devices may recover missing data by using the redundancies, and a retransmission may be required if the missing data exceeds the redundancies. That is, the first RLNC-based redundancies transmitted with the first RLNC data may be used by the receiving devices to restore missing data if some data is missing during the RLNC data transmission. If the missing data exceeds the first RLNC redundancies (e.g., too much data was missing), then the receiving devices will require a retransmission of those missing data. This protocol may also be adapted to a multicast scenario, resulting in a RLNC data transmission and retransmission scheme for multicast delivery.

[01 17] For a RLNC data transmission, at the transmitting device, RLNC data and redundancies may be generated, and retransmission may be performed if required. At the receiving devices, the recovery for missing data and sending a feedback (e.g., NACK) may be performed. The details of these two perspectives will be described below with reference to FIG. 4.

[01 18] FIG. 4 is an example of data packets and redundancies. A transmitting device may generate coded symbols for every m data packets with n redundancies as depicted in FIG. 4. It may be assumed that all data packets and redundancies have the same size, such as defined by the maximum transfer unit (MTU) size as defined by the underlying Layer 2 forwarding. Each redundancy may be generated as a random linear sum of m data packets (i.e., equation (2)).

1,2, ... , n, Equation 2

[01 19] In the equation (2), kj_j may be a random coefficient of the i\ h data packet to generate the /th redundancy. A vector form of data packets and redundancies may be denoted as P = (Pi_< p₂, ... , Pml R = i^ri_> r_2> - _> r_n}· Then, the redundancy generation may be represented in equation (3).

R = KP, Equation 3

[0120] In the equation (3), K may be a n x m matrix in which k,_j is a (/, j)’ th element. The congestion window (i.e., cwnd) may be the sum of m data packets and r redundancies as represented by the above equation (1).

[0121] The network code rate (ncr) may be the ratio between the data packets and cwnd as represented by equation (4). ncr =—— Equation 4 m+r

[0122] Given the mapping of IP transactions to ETP flows, as shown in FIG. 3, it may be important to align the cwnd, and therefore the number of data packets m, to the size of the IP transaction that is being transported over the ETP flow. This may avoid the issue that no data packets can be generated if the IP transaction is smaller than m packets (i.e., since there is not enough to generate sufficient random linearly codes). Hence, a virtual number of data packets m_v and its resulting (virtual) cwndv which may be adjusted (for coding purposes) based on cwnd as equation (5).

m_v = min (length(/ ⁷ transaction ) / fragmen t_size, rri) Equation 5

[0123] In the equation (5), the fragment_size may be the specific size of IP transaction fragmentation. For instance, if sending a very large HTTP response from one ETP to another ETP as an IP transaction, the cwnd will finally be determined by the‘leftover’ data packets after all others have been sent in a full (real) cwnd.

[0124] At 502, the method 500 comprises receiving a first feedback for the first RLNC data from each receiving device in the multiple receiving devices. That is, at 502, the receiver may be configured to receive a first feedback for the first RLNC data from each of the multiple receiving devices.

[0125] In an embodiment, a feedback (e.g., the first feedback received at 502) from one of the multiple receiving devices may be a Negative-Acknowledgment feedback (i.e., NACK). For example, a WTRU may use either an empty NACK or a non-empty NACK to show that whether transmitted RLNC data has been successfully received or not. For example, a WTRU may use an empty NACK to show that the first RLNC data has been successfully received, and may use a non-empty NACK to show that some data or all data in the first RLNC data was not received (e.g., some data or all data was missing). Therefore, it will be appreciated that the term “NACK” (or“NACKs”) in this application might means either empty NACK or non-empty NACK.

[0126] It will be appreciated that the term“first feedback” is intended to differentiate it from other feedbacks which will be received by the receiver for other RLNC data transmissions in the following processes. Therefore, the term“first” here is not intended to be limiting to those feedbacks received by the receiver for the first RLNC data at 502. Similarly, in the following embodiments, such terms like“second feedback” and“third feedback” may be used for similar purposes (e.g., for describing those feedbacks sent from WTRUs) and they are intended to differentiate from each other. It will be appreciated that unless otherwise indicated, those feedbacks (e.g., first feedback, second feedback and third feedback) may have the same or similar forms.

[0127] The first feedback generation and transmission will be briefly described as follows. If there is data missing in the first RLNC data with redundancies, a WTRU may first try to recover the missing data by using redundancies. The maximum number of recovery (e.g., the maximum number of missing data packets which could be recovered by using received redundancies) may be equal to the number of received redundancies. If the number of missing data does not exceed the number of received redundancies, the WTRU may be able to recover the missing data and then send an empty NACK to the base station. However, if the number of missing data exceeds the number of received redundancies, the WTRU may not be able to recover the missing data due to a lack of network code knowledge. Hence, the WTRU may need to send a non-empty NACK with an indication of missing data after receiving the last packet in the first RLNC data. Detail description of NACKs for RLNC data from the multiple WTRUs will be given with reference to FIG. 7 below.

[0128] Since the last packet can be lost, however, the receiver may need to decide whether the last packet is lost or not to send the aforementioned NACK and avoid infinite waiting. A WTRU may decide the last packet is lost if no packet arrives within a maximum waiting time. For example, if the congestion window is 4 and the second packet is successfully received, a WTRU may decide the third packet is lost if the packet is not received within the maximum waiting time. After deciding the third packet is lost, the WTRU may wait for the fourth packet and decide the forth packet is lost if the packet is not received within the maximum waiting time too.

[0129] The maximum waiting time may be constrained as the sum of the network latency and the packet transmission time at the sender. This sum may be measured at the WTRU as the inter-arrival time of each packet. Hence, the mean inter-arrival time may be used as an approximation of the maximum waiting time. [0130] In an embodiment, a feedback (e.g., the first feedback received at 502) from a receiving device may be a NACK/ACK feedback. For example, a WTRU may use a ACK to show that the first RLNC data has been successfully received, and use a NACK to show that some data or all data in the first RLNC data was missing.

[0131] Although the above embodiments illustrated different forms of feedbacks from the multiple receiving devices, they are not intended to be exclusive or be limiting to the present application. The multicast flow control according to this application can adopt any feedback which can help to realize the principle of this application. In the following description, unless otherwise indicated, NACK will be taken as an example of the feedback from the multiple receiving devices for RLNC data transmission.

[0132] At 503, the method 500 may comprise: determining whether a first condition has been satisfied by the received first feedbacks. That is, at 503, the processor may be configured to determine whether a first condition has been satisfied by the received first feedbacks. If the first condition has been satisfied, then at 504, the method 500 may further comprise: dividing the multiple receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices. That is, at 504, the processor or the transmitting device may be further configured to divide the multiple receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices. It will be appreciated that the term“divide” here in this application does not mean that the multiple receiving devices will be physically divided into different groups. The term“divide” means that the multiple receiving devices will be classified into different groups (either congested group or non-congested group) in order to perform different processes to the different groups for the multicast flow control according to this application.

[0133] In an embodiment, the first condition may be the number of missing data in RLNC data transmission is greater than a multicast group division criteria. Here in this application, the definition of missing data means those data transmitted from the transmitting device but not received by a receiving device. For example, there is a network congestion and thus a portion of RLNC data transmitted from a base station may not be received by a WTRU. In that case, the portion of RLNC data may be referred to as missing data.

[0134] For example, a NACK from a WTRU may indicate the number of missing data which was not received by the WTRU in an immediately previous RLNC data transmission. The multicast group division criteria may be a predetermined threshold value. For example, the threshold value may be predetermined by the base station before performing the method 500. The threshold value may also be predetermined by the base station before the method 500 reaches 503. The threshold value may also be predetermined by a user. The multicast group division criteria may also be a dynamic parameter which may be updated each time the transmitting device transmits RLNC data to the multiple receiving devices.

[0135] In this embodiment, after receiving the first NACKs for the first RLNC data from the multiple receiving devices (e.g., a multicast group of WTRUs), the transmitting device may determine whether the number of missing data in RLNC data transmission (i.e., the number of data not received by a WTRU) is greater than a multicast group division criteria. If all of the received first NACKs are empty NACKs (e.g., all WTRUs are non-congested or all first RLNC data has been successfully received by all WTRUs), then it’s not necessary for the transmitting device to determine whether the first condition has been satisfied because no data was missing. If some of the first NACKs were received with an indication of missing data (e.g., some of the first NACKs are nonempty NACKs), the transmitting device may decide whether the multicast group is kept or divided, since keeping a multicast group may be beneficial in terms of network bandwidth efficiency even though some receiving devices (e.g., non-congested WTRUs) may undergo a transmission rate loss. For those receiving devices whose missing data exceeds the multicast group division criteria, the transmitting device may determine that the first condition has been satisfied by the received first NACKs, and thus the multicast group may be divided into a first non-congested group of receiving devices (e.g., a first non-congested group of WTRUs) and a first congested group of receiving devices (e.g., a first congested group of WTRUs). For example, those WTRUs whose first NACKs have satisfied the first condition (e.g., the missing data exceeds the multicast group division criteria) may be divided into the first congested group of WTRUs.

[0136] In window-based transmission rate adaption, rate control may be realized generally by an additive increase, multiplicative decrease (AIMD) algorithm that may be in protocols such as TCP. This may ensure that the back-off behavior is compatible to TCP, which may be referred to as TCP friendly.

[0137] For a non-congested group of receiving devices, the transmitting device (e.g., the based station) may control cwnd to adjust the transmission rate. If the transmitting device receives an empty NACK for transmitted data, the transmitting device may decide the network is not congested. Then the transmitting device may increase the cwnd toward increasing network coding rate (ncr). cwnd at time t may be notated as cwnd(t), and, if the network is not congested (i.e., all data transmitted from the transmitting device has been received by the multiple receiving devices), the cwnd of the next time increase may be indicated by the following equation (6).

cwnd( t + 1) = min ( wnd_max, cwnd( t) + a) Equation 6 [0138] In equation (6), a may be the additive factor (i.e., of AIMD) and cwndmax may be a configurable maximum window size. In order to align with the network coding based data transmission, this general scheme may need translation for the dimensioning of the data versus redundancy packets in the new congestion window. Hence, the equation (5) may be translated by defining cwnd as the sum size of data packets and redundancies. If the cwnd(t) is the sum of m(t) data packets and r(t) redundancies as equation (7), then the next time cwnd(t+1) will be as equation (8).

cwnd(t ) = m(t) + r(t) Equation 7 wnd(t + 1) = m(t + 1) + r(t + 1) Equation 8

[0139] In equation (8), m(t + 1) = m(t) + a, and r(t + 1) = r(t) (i.e., the data packet size increases while the redundancies remain fixed). This reflects the increased‘confidence’ in regards to the network quality (i.e., due to the increasing absence of congestion).

[0140] If cwnd(t+1) reaches the maximum size ( cwndmax ), data packet may increase while the redundancies decrease as shown in the following equation (9).

m(t + 1) = min (cwnd_max, m(t) + a ) and r(t + 1) = cwnd_max— m(t + 1) Equation 9

[0141] In one or more embodiments, there may be operations for the implementation of the techniques described above.

[0142] In an embodiment, the first condition may be the number of missing data in RLNC data transmission is continuous in a number of in-sequence transmissions. The number of the insequence transmissions may be predetermined by the transmitting device before the method 500. The number of the in-sequence transmissions may also be predetermined by the transmitting device before the method 500 reaches 503. The number of the in-sequence transmissions may also be predetermined by a user.

[0143] For example, the number of in-sequence transmissions may be two, which means two successive RLNC data transmissions. In an embodiment, assuming that before the first RLNC data transmission at 501 , the base station already transmitted other RLNC data to the multicast group of WTRUs and then got NACKs from the multicast group of WTRUs. Let’s assume that the NACK from WTRU 102a shown in FIG. 1A indicated that the number of missing data (e.g., the number of missing data packets) in this RLNC data transmission for WTRU 102a was 3. Then, the base station transmitted the first RLNC data to the multicast group of WTRUs and got the first NACKs from the multicast group of WTRUs. Let’s assume that the first NACK from WTRU 102a for the first RLNC data transmission also indicated that the number of missing data packets in the first RLNC data transmission was 3. Then, the base station may determine that the number of missing data in RLNC data transmission for WTRU 102a is continuous in two in-sequence transmissions, i.e., the first condition has been satisfied by WTRU 102a. Then, the base station may classify WTRU 102a into a congested group (e.g., the first congested group of WTRUs at 504). The base station may perform the above processes to each WTRU in the multicast group and classify each WTRU into either a congested group or a non-congested group, and then finally, it will divide the multicast group of WTRUs into a non-congested group of WTRUs (e.g., the first non-congested group of WTRUs at 504) and a congested group of WTRUs (e.g., the first congested group of WTRUs at 504) accordingly.

[0144] The above mentioned two embodiments about the first condition may be combined together for the purpose of implementing the multicast flow control according to this application. For example, in an embodiment, the first condition may comprise either of the following two parts: (1 ) the number of missing data in RLNC data transmission is greater than a multicast group division criteria; and (2) the number of missing data in RLNC data transmission is continuous in a number of in-sequence transmissions. In this embodiment, the first condition may be satisfied if either of both parts is satisfied. For example, if some WTRUs’ missing data does not exceed the multicast group division criteria but the number of missing data is continuous in a number of in-sequence transmissions, then these WTRUs may be divided into a congested group (e.g., the first congested group at 504).

[0145] In an embodiment, the first condition may comprise both of the following two parts: (1 ) the number of missing data in RLNC data transmission is greater than a multicast group division criteria; and (2) the number of missing data in RLNC data transmission is continuous in a number of insequence transmissions. In this embodiment, the first condition may be satisfied if both parts are satisfied.

[0146] It will be appreciated that although the term“group” (i.e., “congested group” and“non- congested group”) is used to describe an outcome of group division at 504, it does not necessarily mean that there are more than one WTRU in each group. In other words, there might be only one WTRU in a congested group of WTRUs under certain circumstance. Similarly there might be only one WTRU in a non-congested group of WTRUs under certain circumstance.

[0147] Although the first condition has been described with reference to some exemplary embodiments, those embodiments are not intended to be exclusive or be limiting to the present application. The first condition may be any condition which may help to realize the principle of the multicast flow control according to the this application. [0148] As shown in FIG. 5A, the method 500 further comprises: at 505, for the first congested group of receiving devices, retransmitting a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices. Accordingly, the transmitter is further configured to retransmit a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback from each receiving device in the first congested group of receiving devices

[0149] That is, for example, after dividing the multiple WTRUs into the first non-congested group of WTRUs and the first congested group of WTRUs, the base station may transmit a first portion of the first RLNC data to each WTRU in the first congested group of WTRUs.

[0150] The first portion of the first RLNC data is corresponding to those data which has been transmitted from the transmitting device but not received by a receiving device, i.e., missing data. In this application, the terms“first portion” of RLNC data and“missing data” share similar or the same meaning in this application, and unless otherwise indicated, they may be used interchangeably in this application. That is, the first portion of RLNC data will be retransmitted. For example, some data may also be missing in a future RLNC data transmission, e.g., a second RLNC data transmission and a third RLNC data transmission as described below. In that case, those missing data may also be referred to as a first portion of RLNC data, e.g., a first portion of second RLNC data and a first portion of third RLNC data.

[0151] As discussed above, RLNC data may be missing during its transmission because of transmission network’s congestion. If the missing data cannot be recovered by RLNC redundancies transmitted with RLNC data, then a missing data retransmission will be requested and those missing data will be retransmitted. For example, to request retransmission, a WTRU which has not received all RLNC data transmitted from the base station will send a feedback (e.g., a non-empty NACK) to the base station. The feedback may indicate which data was missing in an immediately previous data transmission. After receiving the feedback, the base station may know which data (i.e., the missing data) need to be retransmitted. It will be appreciated that the terms“retransmission” and “retransmit” mean that only missing data (rather than all RLNC data in an immediately previous data transmission) may be retransmitted.

[0152] At 505, the first portion of the first RLNC data may be transmitted using a second transmission rate less than the first transmission rate described above. If the missing RLNC data is transmitted with a lower transmission rate, it will help to successfully transmit more missing data to WTRUs. That is, the multiple receiving devices may successfully receive more data from the transmitting device in a scenario of multicast flow control with a lower transmission rate. The second transmission rate may be determined by using the same way as that for determining the first transmission rate. For example, the second transmission rate may be determined based on a second congestion window of RLNC data transmission. In an embodiment, the second transmission rate may be the same as the first transmission rate. The missing data retransmission will be further described with reference to FIG. 5B below.

[0153] As shown in FIG. 5A, the method 500 further comprises: at 506, transmitting second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate. Accordingly, the transmitter may be further configured to transmit second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate. For example, after dividing the multiple WTRUs into the first non-congested group of WTRUs and the first congested group of WTRUs, the base station may transmit new RLNC data (i.e., second RLNC data) to each WTRU in the first non-congested group of WTRUs. The second RLNC data transmission will be further described with reference to FIG. 5C below.

[0154] FIG. 5B illustrates a preferable embodiment of method 500. It will be appreciated that in this embodiment, those processes which are same as or similar to the ones shown in FIG. 5A will be omitted from FIG. 5B other than the process at 505. The process at 505 needs to be repeated under some circumstances in this embodiment. Therefore, the process at 505 is shown in FIG. 5B in order to make a clear description of this embodiment.

[0155] In this embodiment shown in FIG. 5B, for the retransmission of missing data, the transmitting device also need to get feedbacks from those receiving devices to which the transmitting device transmitted missing data. The transmitting device may perform other processes based on these feedbacks for missing data retransmission. To be more specific, as shown in FIG. 5B, the method 500 may further comprise: at 507, receiving a second feedback from each receiving device in the first congested group of receiving devices; at 508, determining whether a second condition has been satisfied by the received second feedbacks, wherein on a condition that the second condition has not been satisfied by a second feedback from a receiving device, repeating the first portion of the first RLNC data transmission, the second feedback reception and the second condition determination for the receiving device the second feedback of which has not satisfied the second condition.

[0156] The second feedback is similar to the first feedback for RLNC data. The second feedback and the first feedback may share the same form. For example, the second feedback may be NACK, such as an empty NACK indicating that the first portion of the first RLNC data retransmitted has been successfully received or a non-empty NACK indicating that the first portion of the first RLNC data retransmitted has not been successfully received. The second feedback may not be limited to the above example. It may be any other feedback which may help to obtain the principle of this application.

[0157] The second condition may be that the first portion of the first RLNC data has been successfully received by a receiving device in the first congested group of receiving devices. For example, the second condition may be that a second feedback from a WTRU in the first congested group of WTRUs is an empty NACK. It will be appreciated that the second condition may not be limited to the above example. It may be any other condition which may help to obtain the principle of this application.

[0158] If the second condition has not been satisfied, the missing data retransmission at 505, the second feedback reception at 507 and the second condition determination at 508 may be repeated until the first portion of the first RLNC data has been successfully received by all receiving devices in the first congested group of receiving devices..

[0159] In an embodiment, if the second condition has been satisfied by a second feedback from a receiving device in the first congested group of receiving devices, the method 500 further comprises: at 509, transmitting third RLNC data to the receiving device using a fourth transmission rate. If the second condition has been satisfied by the second feedback from each receiving device in the first congested group of receiving devices, then at 509, transmitting the third RLNC data to each receiving device in the first congested group of receiving devices. Accordingly, if the second condition has been satisfied by a second feedback from a receiving device in the first congested group of receiving devices, the transmitter may be further configured to transmit third RLNC data to the receiving device using a fourth transmission rate.

[0160] The fourth transmission rate for the third RLNC data may be determined through the same way of determining the first transmission rate. That is, the fourth transmission rate may be controlled by adapting a congestion window size of RLNC data transmission. For example, the fourth transmission rate may be determined based on the above equation (1 ). In an embodiment, the fourth transmission rate may be the same as the second transmission rate described above. In another embodiment, the transmission rate for the third RLNC data may be less than the first transmission rate.

[0161] The third RLNC data may be new RLNC data. That is, the third RLNC data may be RLNC data different from the first RLNC data. The third RLNC data may also be the same data as the first RLNC data. It will be appreciated that the term“third RLNC data” is used for differentiating it from other RLNC data in this application, and it is not intended to be exclusive or be limiting to the present application.

[0162] Let’s take those three WTRUs (i.e., WTRU 102a, 102b, and 102c) shown in FIG. 1A as an example and assume the three WTRUs are in the first congested group. At 506, the base station will transmit missing data to the three WTRUs. Then, at 507, the base station may receive second feedbacks from the three WTRUs, and at 508, the base station may determine whether the second feedbacks are empty NACKs. Let’s assume that the second feedback from WTRU 102a is an empty NACK which means that the first missing data has been successfully received by WTRU 102a, but the second feedbacks from WTRUs 102b and 102c are non-empty NACKs. Then, the base station may transmit new RLNC data (e.g., the third RLNC data) to WTRU 102a at 509, and retransmit the missing data to WTRUs 102b and 102c at 505 (i.e., repeat the missing data retransmission).

[0163] After transmitting the third RLNC data, the base station may perform processes similar to those at 502, 503, 504, 505 and 506. For example, the base station may receive a feedback for the third RLNC data, determined whether the first condition has been satisfied by the feedbacks for the third RLNC data, and if the first condition has been satisfied, divide WTRUs into a congested group and a non-congested group.

[0164] In an embodiment, if the base station receives non-empty NACKs in which missing data are indicated, the base station may enter a new‘congested’ state for those WTRUs where such a non-empty NACK has been sent. The base station may first retransmit the missing data (e.g., the missing data packets) with a retransmission window ( rwnd) . As discussed herein, the rwnd and cwnd may be interchangeably referred to each other. The missing data retransmission process may be repeated with creating new rwnd buffers until all receivers have confirmed the reception of packets with an empty NACK. Note, for this approach a WTRU may be kept in the congested group until all congested receivers have received the respective missing information. Alternatively, strategies for placing“faster recovering” receivers into the non-congested mode may be used.

[0165] If the missing data retransmission has been successfully completed, the base station may enter the ‘non-congested’ state again for this group of WTRUs. But, because of the previous congested state of the group of WTRUs (e.g., the first congested group), the base station has decreased the cwnd together along with the network coding rate (ncr) for the group of WTRUs, and now has an opportunity to increase the cwnd again (assuming successful transmission continues). The cwnd may be lower from the retransmission due to the congested state, compared to had it stayed in the non-congested state all throughout. Note, as used herein cwnd(t) may be defined as the sum of m(t) data packets and r(t) redundancies as shown in equation (7) above, and the next time cwnd(t+1) is shown in the equation (8). The following equation (10) then follows where d may be the decreasing factor and cwndmin may be the configurable minimal window size. With this, different cwnd values may emerge over time, adjusting to the various conditions of receiver groups in the network.

m(t+ 1) = max (cwndmin, m(t)/d), r(t+1) = min(m(t+1), r(t)) Equation 10

[0166] For unicast-based retransmission, the retransmission window (rwnd) may be maintained on a per receiver basis. Consequently, the congestion window cwnd will be split into individual cwnd after the first congestion occurred. The advantage of this scheme may be faster retransmission, occurring directly after the non-empty NACK is being received for a specific WTRU. The disadvantage may be that with the individual congestion window, transmission to those WTRUs may occur in unicast until they will have‘caught up’ in terms of congestion window (i.e., by reaching the maximum congestion window size).

[0167] For multicast-based transmission, the base station may retransmit any missing data by using an explicit transmission within a separate retransmission window (ni nd). The size of this retransmission window may be determined by the common missing data U over all data symbols that were indicated as being lost in all NACKs (i.e., of those receivers in the congested group) plus the number of redundancies r being added to the retransmitted data, such as shown in the following equation (1 1 ).

rwnd = \U\ +rit Equation 11

[0168] The NACK may be collected in timeslots, defined by an (average or maximum) round trip time (RTT) value. The base station may obtain the RTT value of each NACK by comparing the time between the sending data and receiving NACK for each WTRU. Flence, the base station may need a marking timestamp at each data transmission and compute the RTT for each receiving NACK. This may give the opportunity to collect more than one WTRU in a congested group, which in turn may have its own congestion window assigned after the successful retransmission. With that, the initial multicast group may slowly be sub-divided into smaller sub-groups, which may eventually end in individual unicast transmissions. The advantage here may be better send-to-receiver bandwidth utilization while a disadvantage may be the delayed retransmission due to the slotted nature of gathering NACKs.

[0169] The process at 506 and a preferable embodiment of method 500 will be described in detail as follows. FIG. 5C illustrates a preferable embodiment of method 500. It will be appreciated that in this embodiment, those processes same as or similar to the ones shown in FIG. 5A will be omitted from FIG. 5C. As shown in FIG 5C, the method 500 may further comprise: for the first non- congested group of receiving devices, at 506, transmitting second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate. That is, for the first non-congested group of receiving devices, the transmitter may be further configured to transmit second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate.

[0170] The second RLNC data may be RLNC data different from the first RLNC data and the third RLNC data describe above. The second RLNC data may also be the same data as the first RLNC data or the third RLNC data. It will be appreciated that the term“second RLNC data” is used for differentiating it from other RLNC data in this application, and it is not intended to be exclusive or be limiting to the present application.

[0171] The third transmission rate may be determined by the same way of determining the first transmission rate. For example, the third transmission rate may be determined based on a congestion window (cwnd). Further, the third transmission rate may be related to the second RLNC data transmission including redundancies generation as discussed with reference to the above equation (1 ).

[0172] In an embodiment shown in FIG. 5C, at 510, receiving a third feedback for the second RLNC data from each receiving device in the first non-congested group of receiving devices; at 51 1 , determining whether the first condition has been satisfied by the received third feedbacks, wherein on a condition that the first condition has been satisfied, at 512, dividing the first non-congested group of receiving devices into a second non-congested group of receiving devices and a second congested group of receiving devices, and for the second congested group of receiving devices, at 513, transmitting a first portion of the second RLNC data to each receiving device in the second congested group of WTRUs; for the second non-congested group of receiving devices, transmitting fourth RLNC data to each receiving device in the second non-congested group of receiving device using a fifth transmission rate greater than the third transmission rate.

[0173] Accordingly, the receiver may be further configured to receive a third feedback for the second RLNC data from each receiving device in the first non-congested group of receiving devices. The processor may be further configured to determine whether the first condition has been satisfied by the received third feedbacks. If the first condition has been satisfied, the processor or the transmitting device may be further configured to divide the first non-congested group of receiving devices into a second non-congested group of receiving devices and a second congested group of receiving devices. For the second congested group of receiving devices, the transmitter may be further configure to transmit a first portion of the second RLNC data to each receiving device in the second congested group of WTRUs, and for the second non-congested group of receiving devices, the transmitter may be further configured to transmit fourth RLNC data to each receiving device in the second non-congested group of receiving devices using a fifth transmission rate greater than the third transmission rate.

[0174] The third feedback is similar to the first feedback for RLNC data. The third feedback and the first feedback may share the same form. For example, the third feedback may be NACK, such as an empty NACK indicating that the second RLNC data transmitted has been successfully received or an non-empty NACK indicating that the second RLNC data transmitted has not been successfully received. The third feedback may not be limited to the above example. It may be any other feedback which may help to obtain the principle of this application.

[0175] The first condition has been described above with reference to FIG. 5A.

[0176] A first portion of the second RLNC data is those data missing in the second RLNC data transmission at 506. The process at 513 is similar to the process at 505 shown in FIG. 5A. In an embodiment, the first portion of the second RLNC data may be transmitted with a transmission rate less than the third transmission rate for transmitting the second RLNC data. In another embodiment, the first portion of the second RLNC data may be transmitted with the third transmission rate.

[0177] The fifth transmission rate may be determined through the say way of determining the first transmission rate and the second transmission rate. That is, the fifth transmission rate may be controlled by adapting a congestion window size of RLNC data transmission. For example, the fifth transmission rate may be determined based on the above equation (1).

[0178] FIG. 5D illustrates a preferable embodiment of method 500. It will be appreciated that in this embodiment, those processes same as or similar to the ones shown in FIG. 5A will be omitted from FIG. 5D. As shown in FIG 5D, the method 500 may further comprise: on a condition that the first condition shown in FIG. 5A has not been satisfied, at 515, determining whether a third condition has been satisfied, wherein at 516, transmitting the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition using a sixth transmission rate less than the first transmission rate; and at 517, transmitting, using the sixth transmission rate, sixth RLNC data to each receiving device the received first feedback of which has not satisfied the third condition. In this embodiment, after the first portion of the first RLNC data has been retransmitted to a receiving device at 516, the method 500 further comprises: at 518, transmitting fifth RLNC data to a receiving device the received first feedback of which has satisfied the third condition.

[0179] Accordingly, if the first condition has not been satisfied, the processor is further configure to determine whether a third condition has been satisfied, wherein the transmitter may be further configured to transmit the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition using a sixth transmission rate less than the first transmission rate, and to transmit, using the sixth transmission rate, sixth RLNC data to each receiving device the received first feedback of which has not satisfied the third condition. In this embodiment, after the first portion of the first RLNC data has been retransmitted to a receiving device at 516, the transmitter may be further configured to transmit fifth RLNC data to a receiving device the received first feedback of which has satisfied the third condition.

[0180] The third condition may be that the first feedback from a receiving device is an empty NACK. The third condition may also be that the first feedback from a receiving device shows that it has successfully received the first RLNC data. It will be appreciated that the third condition may not be limited to the above example. It may be any other condition which may help to obtain the principle of this application.

[0181] The sixth transmission rate is lower than the first transmission rate. A lower transmission rate may help to overcome a congested network, thereby helping to transmit the sixth RLNC data and the first portion of the first RLNC data to the receiving devices. The sixth transmission rate may be determined by the same way of determining the first transmission rate.

[0182] As discussed above, the method 500 may be used for the multicast flow control in RLNC data transmission and typically such data transmission will be performed continually. Therefore, the method 500 may be performed cyclically for the multicast flow control. The purpose of FIGs. 5A-5D is to use different embodiments to clearly describe different processes that may be comprised in the method 500. However, FIGs. 5A-5D, each or collectively, may not show the method 500 from a cyclical performance perspective. FIG. 6A and FIG. 6B illustrate two embodiments from this cyclical performance perspective. These two embodiments will be described in detail as follows.

[0183] FIG. 6A is an schematic operational flow chart illustrating an embodiment of a method 600 for multicast flow control according to this application. The basic principle of the method 600 is similar to that of the method 500 shown in FIGs. 5A-5D. There are two difference between the method 600 and the method 500: (1 ) the missing data retransmission described in the method 500 is removed from the method 600; and (2) the method 600 does not distinguish different RLNC data, different missing data or different transmission rates. Therefore, to some extent, the method 600 shown in FIG. 6A and FIG. 6B may be considered as a simplified version of the method 500 from a cyclical performance perspective.

[0184] As shown in FIG. 6A, the method 600 may comprise: at 601 , transmitting RLNC data to multiple receiving devices; at 602, receiving feedbacks (e.g., NACKs) from the multiple receiving devices; at 603, determining whether a first condition has been satisfied by the received feedbacks. The method 600 may further comprise: on a condition that the first condition has been satisfied by the received feedbacks (i.e., Yes at 603), dividing the receiving devices into congested group of receiving devices and non-congested group of receiving devices. The method 600 may further comprise: at 604, increasing transmission rate of RLNC data transmission for the non-congested group of receiving devices and then transmitting new RLNC data (i.e., back to 601 but performing 601 with increased transmission rate and new RLNC data); and if the first condition has not been satisfied (i.e., No at 603), then at 605, decrease transmission rate of RLNC data transmission for the congested group of receiving devices and then transmitting new RLNC data (i.e., back to 601 but performing 601 with decreased transmission rate and new RLNC data). Then the method 600 may continue repeating first condition determination at 603, and on a condition that the first condition has been satisfied, dividing receiving devices into congested group of receiving devices and non- congested group of receiving devices. Therefore, the method 600 may be performed in this cyclical way shown in FIG. 6A.

[0185] FIG. 6B is an operational flow chart illustrating another embodiment of a method 600 for multicast flow control according to this application. This embodiment shown in FIG. 6B is similar to that shown in FIG. 6A. The difference is that in this embodiment, there is a process at 613, i.e., determining whether received feedbacks are all empty (corresponding to the third condition shown in FIG. 5D).

[0186] For example, the base station may start data transmission with an initial cwnd and ncr. After data transmission, the base station may receive NACKs sent from WTRUs. If all NACKs are empty NACKs, which means that all receivers have received data without any missing data (i.e., Yes at 613), then the base station may increase the transmission rate by increasing the cwnd size at 605. If some NACKs are not empty NACKs (i.e., No at 613), the base station may decide whether to divide the multicast group as discussed herein at 614. When some NACKs are not empty NACKs, if the base station decides to keep the multicast group rather than divide it (i.e., No at 614), then the base station may decrease the transmission rate for all WTRUs in the multicast group at 616. However, if the WTRU decides to divide the multicast group (i.e., Yes at 614), the multicast group may be divided into non-congested and congested groups. The base station may increase the transmission rate to the non-congested group, while decreasing the transmission rate to the congested group.

[0187] FIG. 7 illustrates an example operational flow chart for a receiving device (e.g., a WTRU). As shown in FIG. 7, at 701 , the receiver may listen to a RLNC data transmission from the transmitting device. Then at 702, the WTRU may receive RLNC data with redundancies from the transmitting device. After receiving data with redundancies in cwnd, at 703, the WTRU may check if there is missing data, i.e., if missing data retransmission need to be performed. If there is missing data, the WTRU may check if the missing data can be recovered by redundancies. If the missing data can be recovered (i.e., No at 703), then retransmission may not be required, so the WTRU may send an empty NACK to the base station at 704. Then, the WTRU may recover the missing data through the redundancies at 706. However, when the missing data cannot be recovered by using redundancies (i.e., Yes at 703), the WTRU may send a non-empty NACK indicating the missing data at 705, where the indication includes missing data and missing redundancies.

[0188] FIG. 8 illustrates an example of a state machine of the transmitting device (e.g., the base station). The base station may have several multicast groups in either congested or non-congested states. In such a scenario, each group may have an independent state and the base station may control the multicast flow independently for each group. Given the example operation of FIGs. 6A and 6B, a state machine may apply recursively for each multicast group that is being created as part of the recovery process.

[0189] The base station may have several multicast groups, and each group may have an independent state. The base station’s state may start with a‘non-congested’ state as an initial state 801 for Action 1. Action 1 may initialize state machine with the initial state 801 being ‘non- congested’ for any new IP transaction.

[0190] The initial state 801 may have two states as follows: Case A where the Initial state is non- congested state 802; and Case B where the Initial state is congested state 803.

[0191] For the non-congested state 802 there may have two cases as follows: Case C where at least one received NACKs is empty; and/or Case D where all received NACKs are non-empty NACKs.

[0192] In case C, the state may move to a‘Removing members’ state 804 to remove members whose empty NACKs was for the last cwnd of an IP transaction. In case D, all members may be congested, hence, the state moves to congested state 803. The congested state 803 may have the same two cases of non-congested 802 and the state moves may be the same as well.

[0193] In the Removing members state 804, two actions may be made as Action 2 and Action 3. [0194] Action 2 may increase cwnd and recode new cwnd for non-congested group members and for congested group members (the latter may be included only if multicast group division value is equal or below the criteria).

[0195] For Action 3, if the multicast group division value is over the criteria, then create a new state machine in the initial state 801 with congested and decrease cwnd size for congested group members (with 1 being the minimum congestion window size).

[0196] The Action 2 may be mandatory while Action 3 may be performed in the event of the multicast group division (i.e., the multicast group division value is over the criteria). If there are no more members left in the group after removing members whose empty NACKs was for the last cwnd of IP transactions, the group may be destroyed without Action 1 and Action 2 by Case E, where Case E is no more member left.

[0197] FIG. 9 illustrates an example state machine of a receiving device (e.g., a WTRU). The receiving device may start with an idle state and wait to receive data. After receiving data within a cwnd at 901, the WTRU may check the missing data and send the NACK to the sender. If there are no missing data or the receiver successfully decoded the data within the cwnd in Case A, the receiver may send an empty NACK at 902. Flowever, if there is missing data or the receiver cannot successfully decode the data within the cwnd in Case B, the receiver may send the NACK (nonempty NACK) with an indication of the missing data at 903.

[0198] FIG. 10 illustrates an example of a packet format and field types of a data packet. The data packet and the redundancy may have the same format. In the header, the cwnd size may be defined as the number of data and redundancies, and the redundancy size may be defined as the number of redundancies. For instance, if cwnd size is 6 and the redundancy size is 2, then 4 data and 2 redundancies may be transmitted. The index may be defined by the unique number of data or redundancy to indicate the missing data. The flag may denote that whatever follows is data or redundancy. For example, if the flag is 1 , the following is redundancy, then the RLNC sequence is inserted between flag and redundancy. If the flag denotes that the following is data, RLNC sequence can be omitted.

[0199] FIG. 1 1 illustrates an example packet format field types of a NACK packet. The receiver may send a NACK to indicate the missing data or redundancies. The structure of the NACK packet may be as shown in FIG. 10. The NACK size may define the number of missing data or redundancies (this may be equal to the following index size). The elements following after the NACK size are the indices of the missing data or redundancies which are contained in the data packet header. [0200] FIG. 12 illustrates an example of an end-to-edge flow control according to one or more embodiments described herein. Flow control may be used between two clients in 5G networks that realize 5GLAN-based connectivity between UPFs, as depicted in the figure. In this example, it may be assumed that a client may have IP-based applications. The flow control may be implemented between either two clients, implementing the SR component, or between one WTRU (i.e., UE) and the Border SR.

[0201] FIG. 13 illustrates an example of an edge-to-edge flow control according to one or more embodiments described herein. In this example it may be assumed that there are non-modified IP- based WTRUs (i.e., UEs). In such a case, the UPF may act as the SR, implementing the flow control towards either another UPF (which in turn connects to a second WTRU) or towards a service router toward a server as depicted in the figure. Flence, the flow between UPF and service router may be controlled by the protocol as described herein through edge-to-edge perspective.

[0202] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS What is Claimed:

1. A method for transmitting Random Linear Network Coding (RLNC) data, comprising: transmitting first RLNC data to a plurality of receiving devices using a first transmission rate; receiving first feedback messages for the first RLNC data from each of the plurality of receiving devices; determining whether a first condition has been satisfied by the received first feedback messages, on a condition that the first condition has been satisfied, dividing the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of receiving devices, retransmitting a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback messages from each receiving device in the first congested group of receiving devices.

2. The method of claim 1 , wherein the first portion of the first RLNC data is retransmitted using a second transmission rate less than the first transmission rate.

3. The method of claim 2, wherein the first transmission rate is determined based on a first congestion window of RLNC data transmission; and the second transmission rate is determined based on a second congestion window of RLNC data transmission.

4. The method of claim 3 further comprising: receiving a second feedback messages from each receiving device in the first congested group of receiving devices; determining whether a second condition has been satisfied by the received second feedback messages, wherein on a condition that the second condition has not been satisfied, repeating the first portion of the first RLNC data retransmission, the second feedback reception and the second condition determination.

5. The method of claim 4 further comprising: wherein on a condition that the second condition has been satisfied, transmitting third RLNC data to each receiving device in the first congested group of receiving devices using a fourth transmission rate.

6. The method of claim 1 further comprising: for the first non-congested group of receiving devices, transmitting second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate.

7. The method of claim 6, further comprising: receiving a third feedback for the second RLNC data from each receiving device in the first non-congested group of receiving devices; determining whether the first condition has been satisfied by the received third feedbacks, wherein on a condition that the first condition has been satisfied, dividing the first non-congested group of receiving devices into a second non-congested group of receiving devices and a second congested group of receiving devices, and for the second non-congested group of receiving devices, transmitting fourth RLNC data to each receiving device in the second non-congested group of receiving devices using a fifth transmission rate greater than the third transmission rate.

8. The method of claim 1 , wherein on a condition that the first condition has not been satisfied, determining whether a third condition has been satisfied, wherein transmitting the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition; and transmitting sixth RLNC data to each receiving device the received first feedback of which has not satisfied the third condition.

9. The method of claim 8, wherein on a condition that the first condition has not been satisfied, the first portion of the first RLNC data and the sixth RLNC data are transmitted using a sixth transmission rate less than the first transmission rate.

10. The method of claim 8 further comprising: after transmitting the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition, transmitting fifth RLNC data to each receiving device the received first feedback of which has satisfied the third condition.

1 1. A transmitting device for transmitting Random Linear Network Coding (RLNC) data, comprising: a transmitter configured to transmit first RLNC data to a plurality of receiving devices using a first transmission rate; a receiver configured to receive first feedback messages for the first RLNC data from each of the plurality of receiving devices; a processor configured to determine whether a first condition has been satisfied by the received first feedback messages, on a condition that the first condition has been satisfied, the processor is further configured to divide the plurality of receiving devices into a first non-congested group of receiving devices and a first congested group of receiving devices, and for the first congested group of receiving devices, the transmitter is further configured to retransmit a first portion of the first RLNC data to each receiving device in the first congested group of receiving devices based on the first feedback messages from each receiving device in the first congested group of receiving devices.

12. The transmitting device of claim 11 , wherein the first portion of the first RLNC data is retransmitted using a second transmission rate less than the first transmission rate.

13. The transmitting device of claim 12, wherein the first transmission rate is determined based on a first congestion window of RLNC data transmission; and the second transmission rate is determined based on a second congestion window of RLNC data transmission.

14. The transmitting device of claim 13, the receiver is further configured to receive second feedback messages from each receiving device in the first congested group of receiving devices; the processor is further configured to determine whether a second condition has been satisfied based on the received second feedback messages, wherein on a condition that the second condition has not been satisfied, the transmitting device is configure to repeat the first portion of the first RLNC data transmission, the second feedback reception and the second condition determination for the receiving device the second feedback of which has not satisfied the second condition.

15. The transmitting device of claim 14, the transmitter is further configured to, wherein on a condition that the second condition has been satisfied, transmit third RLNC data to each receiving device in the first congested group of receiving devices using a fourth transmission rate.

16. The transmitting device of claim 1 1 , the transmitter is further configured to, for the first non-congested group of receiving devices, transmit second RLNC data to each receiving device in the first non-congested group of receiving devices using a third transmission rate greater than the first transmission rate.

17. The transmitting device of claim 16, the receiver is further configured to receive third feedback messages for the second RLNC data from each receiving device in the first non- congested group of receiving devices; the processor is further configured to determine whether the first condition has been satisfied by the received third feedback messages, wherein the transmitting device is further configured to, on a condition that the first condition has been satisfied, divide the first non-congested group of receiving devices into a second non- congested group of receiving devices and a second congested group of receiving devices, and the transmitter is further configured to, for the second non-congested group of receiving devices, transmit fourth RLNC data to each receiving device in the second non-congested group of receiving devices using a fifth transmission rate greater than the third transmission rate.

18. The transmitting device of claim 1 1 , wherein the processor is further configure to, on a condition that the first condition has not been satisfied, determine whether a third condition has been satisfied, wherein the transmitter is further configured to transmit the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition, and to transmit sixth RLNC data to each receiving device the received first feedback of which has not satisfied the third condition.

19. The transmitting device of claim 18, wherein on a condition that the first condition has not been satisfied, the first portion of the first RLNC data and the sixth RLNC data are transmitted using a sixth transmission rate less than the first transmission rate.

20. The transmitting device of claim 18, the transmitter is further configured to: after transmitting the first portion of the first RLNC data to each receiving device the received first feedback of which has satisfied the third condition, transmit fifth RLNC data to each receiving device the received first feedback of which has satisfied the third condition.