AP Function Classification & Requirements May 2003 doc.: IEEE 802.11-03/229r1 July 2004 AP Function Classification & Requirements CHENG Hong, Saravanan GOVINDAN (Panasonic) WNG 12th July 2004 Cheng Hong, Saravanan Govindan Tan Pek-Yew, Matsushita Electric Ind.

Problems with Spilt Architectures July 2004 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

Problems with Spilt Architectures July 2004 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) MAC_Data_ _Service MLME_AP MSDU_to_LLC MSDU_from_ _LLC MLME_AP_ _Services Power_Save_ _Monitor System Blocks System Processes ? Cheng Hong, Saravanan Govindan

Considerations for Inter-operable Split Architectures July 2004 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

The Needs for AP Function Classifications July 2004 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

The Needs for AP Function Classifications May 2003 doc.: IEEE 802.11-03/229r1 July 2004 The Needs for AP Function Classifications Operational Sequence (3) 802.11 Services Functional Blocks (1) Verification of Association Request (a1) Association Service (a1) (a2) Updation of Association Entry (a2) (d1) (d2) Distribution Service This is a pictorial representation of the requirements for AP Functional Classifications (from Slide 5) (1) is the Functional Blocks of the appropriate granularity between System Blocks and System Processes Study Group needs to extend on this to cover all 802.11 services (2) indicates the dependency relations between Functional Blocks Inter-operability among distinct split architectures can be achieved by establishing standardized interfaces among the Functional Blocks (3) is the sequence in which Functional Blocks are to be processed at an AP or AC Dependencies from (2) are exhibited in the Operational Sequence E.g. The Traffic Aggregation & Distribution Block is an example of classifications It is a result of the current market trend of shared WLAN infrastructure among multiple ISPs Traffic related to one ISP needs to be aggregated and distinguished from that of another Aggregation Functional Block is likely to be part of Distribution service – however complete dependencies need to be analyzed Traffic Aggregation & Distribution (d1) Functional Block Relations (2) Functional Block (d2) Cheng Hong, Saravanan Govindan Tan Pek-Yew, Matsushita Electric Ind.

The Needs for AP Function Classifications July 2004 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

Possible items for Standards July 2004 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