NOTE - this is for a centralized controller based deployment.
Basically, the gist is that each radio (2.4 and 5) on the AP will correspond to either port 1 or port 2 in the LAG.
The switch must be configured to support a LAG based on Source IP address (from the controller). There will be two GRE tunnels built and based on the previous statement, traffic will always enter the appropriate port to the AP. The issue isn't the upstream traffic...it's the downstream.
If you consider the following statements:
1. Most Ethernet switches support Etherchannel load-balancing based on some combinations of the 5-tuple <src mac, dest mac, src IP, dest IP, protocol>
2. In a centralized WLAN architecture, all traffic tunneled between the AP and the control have the same outer IP header and 5-tuple
So, from a LAG perspective...all traffic looks the same and is therefore hashed out in the same manner.
Aruba intends to initally solve this by configuring two consecutive IP addresses to the controller so that alternate IP addresses can be used for different GRE tunnels between the AP and the controller. This ensures traffic from the controller to the AP will have different source IP addresses in the outer IP header based on the destination radio interface.
At the end of the day, the AP aggregate throughput is < 1Gbps.