1. doc.: IEEE 802.11-14/593r2 Submission May 2015 Adrian Stephens, Intel CorporationSlide 1 IEEE 802.11 as a “component” Date: 2015-06-03 Authors:

2. doc.: IEEE 802.11-14/593r2 Submission Introduction This submission is intended to provoke discussion about whether there is a need to make 802.11 more manageable. May 2015 Adrian Stephens, Intel CorporationSlide 2

3. doc.: IEEE 802.11-14/593r2 Submission What is a component? For the purpose of this submission, a component has a defined function and defined external interfaces. The component doesn’t care how it is used, provided that the use of the component matches the constraints of its defined external interfaces. It should be possible to swap implementations of the component from different sources provided those implementations are compliant to the defined functions and external interfaces. May 2015 Adrian Stephens, Intel CorporationSlide 3

4. doc.: IEEE 802.11-14/593r2 Submission Is 802.11 a component now? Answer: No We have these main impediments: –No concrete definition of our management interface, defined by various SAP primitives –A “theoretical” MIB of which there is no compliant implementation. Because its size is unwieldy (200+ pages), and because it’s generally written “at gunpoint” by a non-expert, its effectiveness can be questioned. –Lack of clarity as to whether the SME is part of the STA or not. There are “shall statements” for it, but no adequate interface to control it. May 2015 Adrian Stephens, Intel CorporationSlide 4

5. doc.: IEEE 802.11-14/593r2 Submission If not, how do we cope now? The Station Management Entity has its own defined interfaces into the STA. These might match some of the abstract interfaces, but many do not. It is not possible to construct any workable device by bolting together “off the shelf” components. Instead, the construction of a working device from an 802.11 MAC is more akin to hand-cutting bolts to assemble a fire-arm in the era before Mr Whitworth. May 2015 Adrian Stephens, Intel CorporationSlide 5

6. doc.: IEEE 802.11-14/593r2 Submission What benefits might accrue from a component 802.11? For a system architecture that has no need to manage 802.11 as a component – we can carry on as we are. –What is our long-term understanding of the evolution of a converged network? 3GPP find it difficult to integrate tightly at the management plane because there is nothing standard on our side currently to integrate with. But, 5G brings about an opportunity and a challenge. 802.11 is naturally the right technology to meet certain of the usage models described by NGMN. In order to bring this about, we need to change mind-set, and view 802.11 as a component that operates within a system architecture defined by outside IEEE. If, in the long term, the converged network is owned by the operators, we need to make our technology accessible to them. May 2015 Adrian Stephens, Intel CorporationSlide 6

7. doc.: IEEE 802.11-14/593r2 Submission What work would have to be done? Determine where this work should be done. Is this our job, or a job for the WFA, or a job for 3GPP? Go and talk to our “customers” and determine which features need to be managed. Create a modular and small management interface with a small basic management set, and optional extensions for specific features. Research and use an accessible language for expressing structures – netconf / yang a possible contender (802.1) May 2015 Adrian Stephens, Intel CorporationSlide 7

8. doc.: IEEE 802.11-14/593r2 Submission What has already been done Is the work of 802.21 relevant here? What IETF standards are relevant? Relevance of OmniRAN What level in in the stack? May 2015 Adrian Stephens, Intel CorporationSlide 8

9. doc.: IEEE 802.11-14/593r2 Submission Straw poll This idea is worth pursuing –Yes 8 –No 1 –Abstain 1 May 2015 Adrian Stephens, Intel CorporationSlide 9

10. doc.: IEEE 802.11-14/593r2 Submission Discuss next steps Polish up this message in 802.11 Enlist support of 802.1 and 802.21 In any order: –Identify “customers” – i.e. those organizations that define an architecture we might want to fit into –Choose customers that meet a strategic vision for role of 802.11 –Go speak to the customers and identify requirements –Determine schedule that meets customer requirements Choose venue for doing the work Choose a “level” in the architecture for the interface. There may be a hierarchy of interfaces. Don’t be too low a level of abstraction. Identify what standards for interfaces already exist Choose a technology for interface Create a task group to write the “stuff” Relax and have a nice cup of tea May 2015 Adrian Stephens, Intel CorporationSlide 10

11. doc.: IEEE 802.11-14/593r2 Submission Key Discussion Points Who is the customer for this interface? Are we trying to manage the AP or the non-AP STA? How do we sustain the ability of implementers to differentiate? What is the level of granularity? Is 802.11 the right place to define this? What kinds of organization would support, and what oppose this? May 2015 Adrian Stephens, Intel CorporationSlide 11