Understanding Multi-Band, Multi-Channel Concept in IEEE 802.11be

 
Slide 1
 
Sai (Cypress)
 
Multi-Band Multi-Channel Concept
in IEEE 802.11be – A Simple Study
 
Date:
 2019-07-15
 
New ways of operating in bands
Efficient use of spectrum
Leveraging underutilized spectrum
Increased data rates
Network load balancing
Dynamic fast switching between bands/channels
 
Slide 2
 
Sai (Cypress)
 
Why Multi Band Multi Channel (MBMC)?
 
The following are the usage models envisioned for MBMC
operation
Let us look at the typical spectrum below (just representative only)
 
 
 
The BSS may be formed in any single band or can be formed
with multiple band aggregation
There are pros and cons of the above
 
Slide 3
 
Sai (Cypress)
 
Usage Models from Channels Perspective
 
Today’s 802.11a/b/n/ac/ax operate fully in only one band
There are two modes of operation today in Single Band
Single band contiguous
Ex: 20 MHz BSS or 40 MHz BSS or 80 MHz BSS or 160 MHz BSS
Single band non-contiguous
Ex: 80+80 MHz BSS
 
 
 
 
 
 
 
 
Routers are available for above devices
 
Slide 4
 
Sai (Cypress)
 
Single Band Operation
 
Can form BSS across multiple bands
Two ways of Operation
Concurrent asynchronous
Concurrent synchronous
In both cases, we can have APs and non AP STAs and depending on what
device is capable we can see few deployment scenarios
Isn't FST already doing part of it?
Is FST sufficient or not?
 
Slide 5
 
Sai (Cypress).,
 
Multi Band Operation
 
Concurrent asynchronous devices have
multiband concurrent operation
Each band operates independently and
simultaneously
Dual band and triband concurrent routers
Different non-AP STA devices can be connected to
different APs in the collocated device
May use BTM Request (802.11v) to transfer from
one band to another band
A concurrent asynchronous non AP STA may
transfer one of its streams from one band to another
to enhance user experience
Delay, packet loss, jitter, load balancing etc
FST protocol can be used
 
 
 
 
 
Slide 6
 
Sai (Cypress).,
 
Concurrent Asynchronous
 
Concurrent synchronous devices have
multiband concurrent operation
All bands and operating channels are combined to
present a single BSS
Can consider today’s 80+80 MHz operation in one
band as an example although this concept extends to
multiple bands
The maximum bandwidth 802.11be is touting is
320 MHz
The operation of the concurrent synchronous device
is similar to what we see as 160 MHz operation in a
single BSS with 80+80 MHz
Will have primary and secondary channels
Non AP STA devices may operate on entire
bands/channels as the AP to which they are
associated or operate in one band/channels or
partial multiple bands/channels
Ex: 80 MHz STA associated with 160 MHz AP today
 
 
 
 
 
 
Slide 7
 
Sai (Cypress).,
 
Concurrent Synchronous
 
AP Asynchronous concurrent and non AP STA has support
for multiple band/channel but can operate on only one
band/channel at any instant
Ex; AP operates on 20 MHz BSS 1 in 2.4 GHz, 80 MHz BSS 2 in 5
GHz and 80 MHz BSS in 6 GHz
Ex: non AP STA has support for all three bands but can operate
(connect) in only one band at a time
Each band has unique MAC address
It is possible that the AP and/or non AP STA may decide to
move all traffic or partial traffic from one band to another
band to enhance user experience
This can be accomplished by FST or agile multiband [1]
Ex: STA based FST and Stream based FST
Block ACKs are independent depending on transparent or
non transparent
IEEE Spec revmd 2.2 already covers it
Helps QoS and load balancing and efficient in power savings
from non AP STA perspective. Fast switching is also
achieved
 
Slide 8
 
Sai (Cypress).,
 
Scenario 1
 
Architecture of AP
 
 
 
 
 
Architecture of non AP STA
 
Slide 9
 
Sai (Cypress).,
 
Scenario 1
 
General STA
architecture of
STA from
revmd 2.3
section 4
 
Multiband architecture
of revmd 2.3 section
4.6 (non transparent
FST)
 
AP is Asynchronous concurrent and non AP STA has support
for multiple band/channel but can operate on those
bands/channels independently and simultaneously at any instant
Ex: non AP STA has support for 20 MHz in 2.4 GHz and 80 MHz in 5 GHz
The association and authentication happens in both bands/channel
simultaneously since non AP STA is capable
Each band can have unique MAC addresses or same MAC address
It is possible that the AP and/or non AP STA may decide to
move all traffic or partial traffic from one band to another band
to enhance user experience
This can be accomplished by FST or agile multiband
There is need for block ACK in case the communication happens
on both channels simultaneously in a fashion scheduled by AP
Although the author and few folks who designed FST claim that this can be
achieved, the IEEE spec is not clear on this aspect wherein the same stream
can be transmitted out of order in both the bands having one universal Block
ACK agreement with a possible reordering mechanism
In case BAs are independent in both bands, then there is a need for scheduler
at upper layer on how to route traffic
Helps QoS, load balancing and fast switching
This will be power hungry from non AP STA perspective as it
has to process all traffic in both channels simultaneously
 
Slide 10
 
Sai (Cypress).,
 
Scenario 2
 
Architecture of AP/non AP STA
 
Slide 11
 
Sai (Cypress).,
 
Scenario 2
 
Multiband architecture
of revmd 2.3 section
4.6 (non transparent
FST)
 
AP is Synchronous concurrent and non AP STA has support for
multiple band/channel but can operate on only one band/channel
at any instant
The primary channel is decided by AP
Any change of the STAs traffic from one channel to another channel can be
done by Agile multiband or FST
AP can have one unique MAC address across bands/channels or different
MAC addresses and non AP STA may have one or multiple MAC addresses
New concepts for 11be
There can be multiple primaries for different bands/channels
Security can be done in one band for all bands
The non AP STA can be parked anywhere (any channel/band)
Need new rules for CCA if the STA is not parked on primary and how to
asynchronously communicate from non AP STA
The above two sub-bullets warrant new protocol mechanisms
Helps QoS, load balancing and efficient spectrum utilization
Efficient from non AP STA perspective
 
Slide 12
 
Sai (Cypress).,
 
Scenario 3
 
Two possible architecture of AP
 
Slide 13
 
Sai (Cypress).,
 
Scenario 3
 
Multiband
architecture of
revmd 2.3
section 4.6,
(transparent FST)
 
Multiband
architecture of
revmd 2.3 section
4.6 transparent FST
as implemented in
open source bonding
driver of linux
kernel 2.0 and
above)
 
AP is Synchronous concurrent and non AP STA has support for multiple
band/channel and can operate on all bands/channels simultaneously but
independently at any instant
The primary channel is decided by AP
Any change of the STAs traffic from one channel to another channel can be done by
Agile multiband or FST
AP has one unique MAC address and non AP STA may have one or multiple MAC
addresses
Non contiguous OFDMA can be used to communicate with the STA and allocation can
happen to STA at any band
New concepts
There can be multiple primaries (
the TGbe may decide against it
) or the non AP STA
may be concurrently connected to different APs
The non AP STA can be parked anywhere (any channel/band)
Need new rules for CCA if the STA is not parked on primary and how to asynchronously
communicate from non AP STA
The above two sub-bullets warrant new protocol mechanisms
Helps QoS, load balancing and efficient spectrum utilization
Efficient from non AP STA perspective
 
Slide 14
 
Sai (Cypress).,
 
Scenario 4
 
AP is Synchronous concurrent and non AP STA has is
similar to AP
Although this appears new, it is new at RF layer to mixed
signal layer and once it reaches PHY, it is processed as a
single stream
Efficient spectrum utilization, peak rate achievement and
also very expensive
Similar to operating STA in 160 MHz mode that is done today
If the AP were to pick channels in different bands efficiently,
then once can reach high spectrum utilization
Power hungry from non AP STA perspectice
 
Slide 15
 
Sai (Cypress).,
 
Scenario 5
 
Revmd 2.3 says the following
Architecture well defined and let us look at the architecture explanation
 
 
 
 
 
 
 
 
 
The architecture already envisions multiband device with support for
multiple bands/channels
 
Slide 16
 
Sai (Cypress).,
 
What is there in revmd?
 
Current draft
Architecture well defined
FST is approx. 9 years old
Security and control can
be redesigned for new
scenarios for 11be
Similarities with MLA
(Document 823/19)
No need to introduce MLO
device concept as it is there
in both the figures.
MLO entitiy is already
there (MLLE is same as in
FST architecture)
See next slide
 
Slide 17
 
Sai (Cypress).,
 
What is there in revmd?
 
MLO Entity already exists. If there is one MAC SAP it is
transparent FST architecture
BA, Security PN is maintained by multiband entity of FST
This does not preclude us developing new feature with same architecture
it TGbe determines that it is required
MLO device is nothing but non transparent FST where
multiple MAC SAPs are exposed to higher layers
Additionally MLO device forces upper layers to make scheduling
decisions based in link conditions
 
Slide 18
 
Sai (Cypress).,
 
Similarities between 0823/19 and Current
Architecture
 
Additionally, if TGbe
wants to redesign FST
there is a way as it does
not preclude
simultaneous operation
(section 11)
It is clear that FST can be
kept alive in both bands at
the same time
It is also clear that the FST
session is kept alive in old
band even if the data
moves in the new band
The author does not
advocate to use FST but
only wants to point out that
architecture exists in draft
and we can create new
features for multi-link by
referencing to it
 
 
Slide 19
 
Sai (Cypress).,
 
What is there in revmd?
 
Bonding driver exists in linux implementation since the inception of
kernel 2.0 of FST in some practically available system and that will
accomplish most of the scenarios outlined in MLA presentation
(Figure courtesy: Carlos/Intel)
 
 
 
 
 
 
 
 
https://www.kernel.org/doc/Documentation/networking/bonding.txt
 
Slide 20
 
Sai (Cypress).,
 
Practical Implementation
 
Multiband architecture in revmd is sufficiently general and allows scope
for any new innovation to support 11be multi-link or carrier
aggregation capabilities
In case the group wants to use FST, then there is a need to modify the
transparent FST to adapt it to the concept of (maybe having multiple
MAC addresses although this concept is extended in bonding driver of
linux kernel 2.0)
Multiband management entity or bonding driver that is already present presents one
MAC SAP to higher layers
Need to clearly spell that security and other control actions in one band
will automatically apply in multiple bands
OCT is there in specification and may need to be simplified
Additionally at higher layer, MPTCP exists and can aggregate links
across technologies and is active in most of the cellular and laptop
products
Most smartphones manufactured after 2016 support it
Based on above points, new architecture as proposed in 0823/19 needs
further study if those architecture concepts are really required and
wants to group to defer any strawpolls
 
 
 
Slide 21
 
Sai (Cypress).,
 
Summary
 
[1] 
https://www.wi-fi.org/discover-wi-fi/wi-fi-agile-
multiband
 
 
Slide 22
 
Sai (Cypress).,
 
References
Slide Note
Embed
Share

Explore the advantages of Multi-Band, Multi-Channel (MBMC) operation in IEEE 802.11be, focusing on efficient spectrum use, increased data rates, and dynamic band switching. Learn about usage models and compare with single-band operations. Discover how MBMC enables concurrent operation across multiple bands for enhanced network performance.


Uploaded on Aug 03, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. June 2019 doc.: IEEE 802.11-19/1231r1 Multi-Band Multi-Channel Concept in IEEE 802.11be A Simple Study Date: 2019-07-15 Name Affiliation Address Phone Email Cypress Semiconductor Corp Sai Nandagopalan snan@cypress.com Submission Slide 1 Sai (Cypress)

  2. June 2019 Why Multi Band Multi Channel (MBMC)? doc.: IEEE 802.11-19/1231r1 New ways of operating in bands Efficient use of spectrum Leveraging underutilized spectrum Increased data rates Network load balancing Dynamic fast switching between bands/channels Submission Slide 2 Sai (Cypress)

  3. June 2019 Usage Models from Channels Perspective doc.: IEEE 802.11-19/1231r1 The following are the usage models envisioned for MBMC operation Let us look at the typical spectrum below (just representative only) 5.0 GHz 5.0 GHz 5.0 GHz 2.4 GHz UNI1 and UNI !! Bands UNI iii and UNI !V Bands UNI V to UNI 1X Bands The BSS may be formed in any single band or can be formed with multiple band aggregation There are pros and cons of the above Submission Slide 3 Sai (Cypress)

  4. June 2019 doc.: IEEE 802.11-19/1231r1 Single Band Operation Today s 802.11a/b/n/ac/ax operate fully in only one band There are two modes of operation today in Single Band Single band contiguous Ex: 20 MHz BSS or 40 MHz BSS or 80 MHz BSS or 160 MHz BSS Single band non-contiguous Ex: 80+80 MHz BSS 80+80 MHz BSS 20 MHz BSS 40 MHz BSS 80 MHz BSS 160 MHz BSS 2.4 GHz 5.0 GHz 5.0 GHz 5.0 GHz UNI1 and UNI !! Bands UNI iii and UNI !V Bands UNI V to UNI 1X Bands Routers are available for above devices Submission Slide 4 Sai (Cypress)

  5. June 2019 doc.: IEEE 802.11-19/1231r1 Multi Band Operation Can form BSS across multiple bands Two ways of Operation Concurrent asynchronous Concurrent synchronous In both cases, we can have APs and non AP STAs and depending on what device is capable we can see few deployment scenarios Isn't FST already doing part of it? Is FST sufficient or not? Submission Slide 5 Sai (Cypress).,

  6. June 2019 doc.: IEEE 802.11-19/1231r1 Concurrent Asynchronous Concurrent asynchronous devices have multiband concurrent operation Each band operates independently and simultaneously Dual band and triband concurrent routers Different non-AP STA devices can be connected to different APs in the collocated device May use BTM Request (802.11v) to transfer from one band to another band A concurrent asynchronous non AP STA may transfer one of its streams from one band to another to enhance user experience Delay, packet loss, jitter, load balancing etc FST protocol can be used 2.4 GHz BSS1 5.0 GHz BSS2 5.0 GHz BSS3 Submission Slide 6 Sai (Cypress).,

  7. June 2019 doc.: IEEE 802.11-19/1231r1 Concurrent Synchronous 2.4 GHz Concurrent synchronous devices have multiband concurrent operation All bands and operating channels are combined to present a single BSS Can consider today s 80+80 MHz operation in one band as an example although this concept extends to multiple bands The maximum bandwidth 802.11be is touting is 320 MHz The operation of the concurrent synchronous device is similar to what we see as 160 MHz operation in a single BSS with 80+80 MHz Will have primary and secondary channels Non AP STA devices may operate on entire bands/channels as the AP to which they are associated or operate in one band/channels or partial multiple bands/channels Ex: 80 MHz STA associated with 160 MHz AP today 5 GHz UNI 1 Example of 1 BSS across multiple bands 5 GHz UNI 3 6 GHz UNI 5 Submission Slide 7 Sai (Cypress).,

  8. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 1 AP Asynchronous concurrent and non AP STA has support for multiple band/channel but can operate on only one band/channel at any instant Ex; AP operates on 20 MHz BSS 1 in 2.4 GHz, 80 MHz BSS 2 in 5 GHz and 80 MHz BSS in 6 GHz Ex: non AP STA has support for all three bands but can operate (connect) in only one band at a time Each band has unique MAC address It is possible that the AP and/or non AP STA may decide to move all traffic or partial traffic from one band to another band to enhance user experience This can be accomplished by FST or agile multiband [1] Ex: STA based FST and Stream based FST Block ACKs are independent depending on transparent or non transparent IEEE Spec revmd 2.2 already covers it Helps QoS and load balancing and efficient in power savings from non AP STA perspective. Fast switching is also achieved Submission Slide 8 Sai (Cypress).,

  9. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 1 Multiband architecture of revmd 2.3 section 4.6 (non transparent FST) Architecture of AP Multiband Management 802.1X 802.1X MAC SAP MAC SAP MACx MLME MLME MACy SME PLME PHYx PHYy PLME Architecture of non AP STA 802.1X General STA architecture of STA from revmd 2.3 section 4 MAC SAP MLME SME PLME Submission Slide 9 Sai (Cypress).,

  10. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 2 AP is Asynchronous concurrent and non AP STA has support for multiple band/channel but can operate on those bands/channels independently and simultaneously at any instant Ex: non AP STA has support for 20 MHz in 2.4 GHz and 80 MHz in 5 GHz The association and authentication happens in both bands/channel simultaneously since non AP STA is capable Each band can have unique MAC addresses or same MAC address It is possible that the AP and/or non AP STA may decide to move all traffic or partial traffic from one band to another band to enhance user experience This can be accomplished by FST or agile multiband There is need for block ACK in case the communication happens on both channels simultaneously in a fashion scheduled by AP Although the author and few folks who designed FST claim that this can be achieved, the IEEE spec is not clear on this aspect wherein the same stream can be transmitted out of order in both the bands having one universal Block ACK agreement with a possible reordering mechanism In case BAs are independent in both bands, then there is a need for scheduler at upper layer on how to route traffic Helps QoS, load balancing and fast switching This will be power hungry from non AP STA perspective as it has to process all traffic in both channels simultaneously Submission Slide 10 Sai (Cypress).,

  11. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 2 Architecture of AP/non AP STA Multiband architecture of revmd 2.3 section 4.6 (non transparent FST) Multiband Management 802.1X 802.1X MAC SAP MAC SAP MACx MLME MLME MACy SME SME PLME PHYx PHYy PLME Submission Slide 11 Sai (Cypress).,

  12. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 3 AP is Synchronous concurrent and non AP STA has support for multiple band/channel but can operate on only one band/channel at any instant The primary channel is decided by AP Any change of the STAs traffic from one channel to another channel can be done by Agile multiband or FST AP can have one unique MAC address across bands/channels or different MAC addresses and non AP STA may have one or multiple MAC addresses New concepts for 11be There can be multiple primaries for different bands/channels Security can be done in one band for all bands The non AP STA can be parked anywhere (any channel/band) Need new rules for CCA if the STA is not parked on primary and how to asynchronously communicate from non AP STA The above two sub-bullets warrant new protocol mechanisms Helps QoS, load balancing and efficient spectrum utilization Efficient from non AP STA perspective Submission Slide 12 Sai (Cypress).,

  13. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 3 Two possible architecture of AP Multiband architecture of revmd 2.3 section 4.6, (transparent FST) Multiband Management 802.1X MAC SAP SME SME MACx MLME MLME MACy PLME PHYx PHYy PLME Multiband architecture of revmd 2.3 section 4.6 transparent FST as implemented in open source bonding driver of linux kernel 2.0 and above) Multiband Management 802.1X MAC SAP MAC SAPx MAC SAPy SME SME MACx MLME MLME MACy PLME PHYx PHYy PLME Submission Slide 13 Sai (Cypress).,

  14. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 4 AP is Synchronous concurrent and non AP STA has support for multiple band/channel and can operate on all bands/channels simultaneously but independently at any instant The primary channel is decided by AP Any change of the STAs traffic from one channel to another channel can be done by Agile multiband or FST AP has one unique MAC address and non AP STA may have one or multiple MAC addresses Non contiguous OFDMA can be used to communicate with the STA and allocation can happen to STA at any band New concepts There can be multiple primaries (the TGbe may decide against it) or the non AP STA may be concurrently connected to different APs The non AP STA can be parked anywhere (any channel/band) Need new rules for CCA if the STA is not parked on primary and how to asynchronously communicate from non AP STA The above two sub-bullets warrant new protocol mechanisms Helps QoS, load balancing and efficient spectrum utilization Efficient from non AP STA perspective Submission Slide 14 Sai (Cypress).,

  15. June 2019 doc.: IEEE 802.11-19/1231r1 Scenario 5 AP is Synchronous concurrent and non AP STA has is similar to AP Although this appears new, it is new at RF layer to mixed signal layer and once it reaches PHY, it is processed as a single stream Efficient spectrum utilization, peak rate achievement and also very expensive Similar to operating STA in 160 MHz mode that is done today If the AP were to pick channels in different bands efficiently, then once can reach high spectrum utilization Power hungry from non AP STA perspectice Submission Slide 15 Sai (Cypress).,

  16. June 2019 doc.: IEEE 802.11-19/1231r1 What is there in revmd? Revmd 2.3 says the following Architecture well defined and let us look at the architecture explanation The architecture already envisions multiband device with support for multiple bands/channels Submission Slide 16 Sai (Cypress).,

  17. June 2019 doc.: IEEE 802.11-19/1231r1 What is there in revmd? Current draft Architecture well defined FST is approx. 9 years old Security and control can be redesigned for new scenarios for 11be Similarities with MLA (Document 823/19) No need to introduce MLO device concept as it is there in both the figures. MLO entitiy is already there (MLLE is same as in FST architecture) See next slide Submission Slide 17 Sai (Cypress).,

  18. June 2019 Similarities between 0823/19 and Current Architecture doc.: IEEE 802.11-19/1231r1 MLO Entity already exists. If there is one MAC SAP it is transparent FST architecture BA, Security PN is maintained by multiband entity of FST This does not preclude us developing new feature with same architecture it TGbe determines that it is required MLO device is nothing but non transparent FST where multiple MAC SAPs are exposed to higher layers Additionally MLO device forces upper layers to make scheduling decisions based in link conditions DS DS MLO Device Common mgmt. signaling across MLO Entity 1 and MLO Entity 2 MAC Addr (M1) MAC Addr (M2) MAC-SAP-a MAC-SAP-b MLO Entity 2 MLO Entity 1 Common BA session, SN/PN, security Common BA session, SN/PN, security STA (MAC/PHY) x STA (MAC/PHY) y STA (MAC/PHY) z Submission Slide 18 Sai (Cypress)., WM WM WM

  19. June 2019 doc.: IEEE 802.11-19/1231r1 What is there in revmd? Additionally, if TGbe wants to redesign FST there is a way as it does not preclude simultaneous operation (section 11) It is clear that FST can be kept alive in both bands at the same time It is also clear that the FST session is kept alive in old band even if the data moves in the new band The author does not advocate to use FST but only wants to point out that architecture exists in draft and we can create new features for multi-link by referencing to it Submission Slide 19 Sai (Cypress).,

  20. June 2019 doc.: IEEE 802.11-19/1231r1 Practical Implementation Bonding driver exists in linux implementation since the inception of kernel 2.0 of FST in some practically available system and that will accomplish most of the scenarios outlined in MLA presentation (Figure courtesy: Carlos/Intel) control Bonding driver: is an open source driver used for bonding multiple network interfaces Allows exposing a single IP/MAC address towards network stack We use existing driver as-is to implement FST data path switching Network LIB wpa_supplicant / hostapd FST Manager User Space Data switch control NL80211 Network stack MAC80211 CFG80211 Data Bonding Driver Traffic Control (TC) FST Manager: implements data switching policy Data Data control wlan1 11ad device wlan0 11ac device Supplicant: Single instance manages both interfaces to control FST state machine Kernel https://www.kernel.org/doc/Documentation/networking/bonding.txt Submission Slide 20 Sai (Cypress).,

  21. June 2019 doc.: IEEE 802.11-19/1231r1 Summary Multiband architecture in revmd is sufficiently general and allows scope for any new innovation to support 11be multi-link or carrier aggregation capabilities In case the group wants to use FST, then there is a need to modify the transparent FST to adapt it to the concept of (maybe having multiple MAC addresses although this concept is extended in bonding driver of linux kernel 2.0) Multiband management entity or bonding driver that is already present presents one MAC SAP to higher layers Need to clearly spell that security and other control actions in one band will automatically apply in multiple bands OCT is there in specification and may need to be simplified Additionally at higher layer, MPTCP exists and can aggregate links across technologies and is active in most of the cellular and laptop products Most smartphones manufactured after 2016 support it Based on above points, new architecture as proposed in 0823/19 needs further study if those architecture concepts are really required and wants to group to defer any strawpolls Submission Slide 21 Sai (Cypress).,

  22. June 2019 doc.: IEEE 802.11-19/1231r1 References [1] https://www.wi-fi.org/discover-wi-fi/wi-fi-agile- multiband Submission Slide 22 Sai (Cypress).,

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#