1. AP Function Classification & Requirements
May 2003
doc.: IEEE /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.

2. 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 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 capabilities but is still not able to serve APs from other architectures
Cheng Hong, Saravanan Govindan

3. 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, 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

4. 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 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
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 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
May 2003
doc.: IEEE /229r1
July 2004
The Needs for AP Function Classifications
Operational
Sequence (3)
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 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.

7. 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

8. 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