AP Function Classification & Requirements

1. AP Function Classification & Requirements CHENG Hong, Saravanan GOVINDAN (Panasonic) WNG 12th July 2004 Cheng Hong, Saravanan Govindan

2. Problems with Spilt Architectures • Diversity of incompatible split architectures (split MAC & split AP) • APs from one vendor do not work with AC from another • Even the MAC can be split in different ways • Most ACs include bulk of 802.11 capabilities • However they are not adaptive to serve APs with dissimilar split functions • E.g. The CAPWAP Architecture Taxonomy indicates Architecture 8 to be capable of bulk of 802.11 capabilities but is still not able to serve APs from other architectures Cheng Hong, Saravanan Govindan

3. MSDU_to_LLC MSDU_from_ _LLC MAC_Data_ _Service MLME_AP MLME_AP_ _Services Power_Save_ _Monitor System Blocks System Processes ? Problems with Spilt Architectures • Standards now specify System Blocks and System Processes • However, current split architecture designs are based on a granularity that is between System Blocks and System Processes • Based on CAPWAP, most split architectures group encryption & decryption together • However, 802.11 shows them to be part of distinct processes, Prepare_MPDU & Defragment within System Blocks, MPDU_Generation & Reception, respectively • Therefore, using System Blocks to classify splits is too broad: Interoperability is difficult to achieve • While using System Processes is too tedious: Interoperability achieved at cost of substantial complexity • So we need an intermediate set of classifications: System Sub-blocks (Functional Blocks) Cheng Hong, Saravanan Govindan

4. Considerations for Inter-operable Split Architectures • Split needs to be based on appropriately granular definition of WLAN functions – in terms of Functional Blocks • Each Functional Block should represent a suitable subset of a 802.11 service • i.e. One set of Functional Blocks for association service, another set for privacy service • Modular design of the functional blocks • Interface between Functional Blocks needs to be structured and defined • Physical placement of Functional Blocks to be left to implementations • Each Functional Block is to interface with selected number of other Functional Blocks; simplifies design & prevents ambiguity • Different split architectures should be possible given a base set of Functional Blocks Cheng Hong, Saravanan Govindan

5. The Needs for AP Function Classifications • First step in addressing interoperability is to classify Functional Blocks based on following needs; • Unambiguous Functional Blocks • Each dealing with an atomic part of a 802.11 service • E.g. Verification of a request, processing encryption/decryption etc. • ‘Clean’ relations between Functional Blocks • Clear flow of operation from one block to another • Operational sequence of Functional Blocks • Order in which AP processes various blocks • Appropriate dependencies should be defined, i.e. Association Functional Blocks processed before Privacy Functional Blocks Cheng Hong, Saravanan Govindan

6. The Needs for AP Function Classifications Operational Sequence (3) 802.11 Services Functional Blocks (1) (a1) Verification of Association Request Association Service (a1) (a2) (a2) Updation of Association Entry (d1) (d2) Distribution Service Traffic Aggregation & Distribution (d1) Functional Block Relations (2) Functional Block (d2) Cheng Hong, Saravanan Govindan

7. The Needs for AP Function Classifications • This architecture sequence is a good start for AP Function Classifications • It can be extended to reflect the new granularity of Functional Blocks and their • dependencies • -Such an architecture sequence • can also be devised for the • MAC Control Plane Cheng Hong, Saravanan Govindan

8. Possible items for Standards • Classification of appropriately granular Functional Blocks • Definition of dependencies among Functional Blocks and their operational sequences • Description/requirements on the basic rules for split • E.g. Which functional block has to be on the WTP, relationship to the PHY, RLC, LLC, etc • Which function has to go with which other functions • Means for modifying operational sequences • APs & ACs of different split architectures to establish appropriate operational sequences based on their mutual capabilities • Operational sequences to be modified in reaction to external conditions – some blocks to be bypassed by a particular AP • Adaptive interface between AP and network, i.e. Distribution System • APs will operate with different realizations of DS based on their particular split architecture • Adaptive interface would ensure that dissimilar split architectures work together Cheng Hong, Saravanan Govindan