Thoughts on AP Functional Descriptions

1. Thoughts on AP Functional Descriptions L. Lily Yang Steve Shellhammer Intel Corp. lily.l.yang@intel.com Stephen.j.shellhammer@intel.com Lily Yang, Steve Shellhammer, Intel

2. Overview • Background & Motivation • How to achieve interoperability? • Scoping for “AP Functional Descriptions” • Requirements and Reality Check • Open Questions for the new SG/TG • Summary & Conclusion Lily Yang, Steve Shellhammer, Intel

3. Background • Original “Access Points”: • Logical AP Functions = One Physical Entity (“AP”) • Subsequently in the industry some vendors have partitioned the AP functionality into different physical entities (Example: AP = AC + WTP) • Logical AP Functions = Combination of Physical Entities AP Functions: Logical AP Functional Descriptions: Logical View Lily Yang, Steve Shellhammer, Intel

4. Motivation: Interoperability • Interest from IETF: defining a protocol between these physical entities to allow interoperability in the WLAN market X-Y Protocol Physical Entity X (Access Controller): From vendor A Physical Entity Y (Wireless Termination Point): From vendor B interoperable Lily Yang, Steve Shellhammer, Intel

5. How to achieve interoperability? IETF interest X-Y Protocol Physical Entity X (AC) Physical Entity Y (WTP) First Step: Need help from IEEE Logical Functions for “AC+WTP” = “AP Functionality” It takes efforts from both IEEE and IETF Lily Yang, Steve Shellhammer, Intel

6. Additional Benefit of “AP Functional Descriptions” • A trend in 802.11 WG: from “link view” to “wireless network view” • 11e, 11n => 11r, 11s • Natural evolution for WLAN architectures • One box AP with BSS-centric view: “Autonomous Architecture” • The need for better coordination to provide inter-BSS services • “Centralized Architecture”: centralized controller for the whole network • “Distributed Architecture”: distributed coordination by peer nodes (example: mesh) • Original AP definitions: interaction with DS is vague • No interoperability within ESS • Need to provide better definitions of ESS and interoperability within ESS Lily Yang, Steve Shellhammer, Intel

7. Why by IEEE 802.11? • The 802.11 WG defines the MAC and PHY layers, which are the basis for construction of an AP • The 802.11 WG embodies the subject matter experts that best understand the workings of an AP and Lily Yang, Steve Shellhammer, Intel

8. Scoping for “AP Functional Descriptions” • What’s in the scope? • Clear logical decomposition of the AP functionality into some logical units (modules, services, functions, or whatever makes sense) • Clear description of the interaction, relationship or interfaces between these logical units • What’s out of the scope? • Physical mapping of these logical units onto physical entities (this implies a specific architecture: belongs to other groups) Lily Yang, Steve Shellhammer, Intel

9. Basic Requirements for “AP Functional Descriptions” • Better description to • Allow WLAN architecture flexibility and innovation • Facilitate interoperability (possibly with additional work done elsewhere) • Provide common framework for existing and future WLAN architecture development Lily Yang, Steve Shellhammer, Intel

10. Reality Check • How future proof can it really be? (Common challenge for any technology development) • Architecture flexibility Support infinite number of arbitrary architectures • Figure out the relevant architectures in today’s market • Study the evolutional path from past and present • Keep eyes on the emerging architectures on the horizon • Interesting architecture examples for study (from IETF CAPWAP WLAN Architecture Taxonomy Document): • Autonomous Architecture • Centralized Architecture (with centralized Access Controller) • Distributed Architecture (peer-to-peer coordination) Lily Yang, Steve Shellhammer, Intel

11. Need to form a new SG • To work on better “AP Functional Definitions” • Some open questions for SG to investigate • What do we have today in the Standards (as starting points)? • What is missing, lacking, or confusing? • How to approach the functional decomposition (methodology, granularity)? • How to describe the interface or interaction? • How to better separate data plane and control plane? • What kind of documents will be produced in the end? • What impact does it have on other 802.11 groups? Lily Yang, Steve Shellhammer, Intel

12. Reference Model in 802.11(Clause 5 & 10) MAC_SAP MAC MLME Station Management Entity (SME) MLME_SAP MAC MIB PHY_SAP PLCP MLME_PLME_SAP PLME PMD_SAP PMD PHY MIB PLME_SAP Does this represent the whole picture accurately? Lily Yang, Steve Shellhammer, Intel

13. AP Architecture in IAPP (11F) Can we generalize this beyond IAPP? Lily Yang, Steve Shellhammer, Intel

14. Data Plane Architecture from 11i Is this a better approach? Lily Yang, Steve Shellhammer, Intel

15. Suggested Next Step for IEEE 802.11 WG • Form a new IEEE 802.11 SG/TG to provide better AP functional descriptions • Clear logical decomposition of AP functionality • Clear description of the interfaces • Harmonize across different WLAN architectures • Centralized Architectures (with IETF CAPWAP) • Distributed Architecture (with IEEE 802.11s) Lily Yang, Steve Shellhammer, Intel

16. Summary • Share our thoughts on AP Functional Descriptions • Why? Interoperability. • How? First step is to have common understanding of what constitute “AP functions”. • What? Functional decomposition and interfaces. • Very important first step toward interoperability • Other groups can use this and develop additional protocols to achieve interoperability for a particular architecture • Conclusion: a new study group is needed in 802.11 WG to accomplish this. Lily Yang, Steve Shellhammer, Intel