110 likes | 134 Views
IEEE 802.11 as a “component”. Authors:. Date: 2015-06-03. This submission is intended to provoke discussion about whether there is a need to make 802.11 more manageable. Introduction. For the purpose of this submission, a component has a defined function and defined external interfaces.
E N D
IEEE 802.11 as a “component” Authors: Date: 2015-06-03 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
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. 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. • 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. 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. Research and use an accessible language for expressing structures – netconf / yang a possible contender (802.1) 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
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? Key Discussion Points Adrian Stephens, Intel Corporation