IEEE 802.11 as a “component”

IEEE 802.11 as a “component” Authors: Date: 2015-05-13 Adrian Stephens, Intel Corporation

This submission is intended to provoke discussion about whether there is a need to make 802.11 more manageable. Introduction Adrian Stephens, Intel Corporation

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. What is a component? Adrian Stephens, Intel Corporation

Short answer: no. • Longer answer: no way. • We have these main impediments: • No concrete definition of our management interface • 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. Is 802.11 a component now? Adrian Stephens, Intel Corporation

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. If not, how do we cope now? Adrian Stephens, Intel Corporation

For a system architecture that has no need to manage 802.11 as a component – we can carry on as we are. 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 threat. 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. What benefits might accrue from a component 802.11? Adrian Stephens, Intel Corporation

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. Use an accessible language for expressing structures – ASN.1 might be good enough, but we don’t have many ASN.1 experts. Define a generic mechanism for mapping these interfaces into a concrete stream of octets. What work would have to be done? Adrian Stephens, Intel Corporation

Is the work of 802.21 relevant here? What IETF standards are relevant? Relevance of OmniRAN What level in in the stack? What has already been done Adrian Stephens, Intel Corporation

This idea is worth pursuing • Yes 8 • No 1 • Abstain 1 Straw poll Adrian Stephens, Intel Corporation

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 Discuss next steps Adrian Stephens, Intel Corporation

IEEE 802.11 as a “component”