omniran13 0056 00 ecsg IEEE 802 Omni RAN

omniran-13 -0056 -00 -ecsg IEEE 802 Omni. RAN EC SG July 2013 Conclusion Max Riegel (EC SG Chair) 1

omniran-13 -0056 -00 -ecsg Omni. RAN EC SG Jul ‘ 13 Objectives • When renewing the Omni. RAN EC SG on March 22 nd the IEEE 802 EC refined the objectives for the Omni. RAN EC SG: – To perform a gap analysis that shows what pieces of work that are relevant to 802 (standards and standards under development) are not covered by existing external SDOs (IETF, 3 GPP, . . . ) and internal, and socialize that analysis with those SDOs; – Having performed that gap analysis, define a crisp scope of the ECSG (target 15 words or less); – Define what piece(s) of work within that scope (a) fall legitimately within 802's remit and (b) are achievable within an 802 activity. • The objectives were addressed by the study group and the results were shared with all the IEEE 802 working groups. Incorporating the feedback from the working groups, Omni. RAN EC SG created a plan for progressing its work. – Requesting extension of the EC SG until Nov ‘ 13 to create a PAR and 5 C for a ‘Recommended Practice for Network Reference Model and Functional Description of IEEE 802 based Access Networks’ 2

omniran-13 -0056 -00 -ecsg Gap Analysis • Deploying a simplistic network reference model, Terminal R 2 R 1 Ctrl Access R 3 a couple of use cases were investigated Interne t – 3 GPP Trusted WLAN Access to EPC • TS 23. 402 V 11. 6. 0 (2013 -03) – Zig. Bee SEP 2 Smart Grid Use Case • Zig. Bee docs-09 -5449 -33 -0 zse – SDN-based Omni. RAN Use Case • Existing IEEE 802 specifications seem to fulfill the requirements. – However it was less than obvious how the pieces of IEEE 802 are fitting together • … still not clear how MACsec should provide point-to-point links across a bridged access network for roaming terminals • There is need for better documentation how IEEE 802 protocols work together to create access networks for particular deployments • There is no consistent way how IEEE 802 handles the IEEE 802 information elements going over IP protocols 3

omniran-13 -0056 -00 -ecsg External control of IEEE 802 Access Network Scanning ANQP AAA DHCP Policy Configuration Application ? Network Selection Association Authentication Authorization Accounting Host Configuration Application Policy Control Application Host Config Release Disassociation Accounting IEEE 802 Access Technologies IEEE 802 ext. i/f 4

omniran-13 -0056 -00 -ecsg Topics for Standardization in IEEE 802 • The potential gaps in IEEE 802 technologies, if any, should be addressed by the related IEEE 802 WGs • Establishing a common approach of specifying ‘external’ control into IEEE 802 technologies would require: – a specification describing the Network Reference Model and listing the DL and PHY control functions required for access networks and SDN • Description to facilitate mapping of protocols to service requirements – a specification on the usage of IP protocols for the transport of IEEE 802 attributes and the definition of IEEE 802 attributes for such IP protocols • Topic for the joint IEEE 802 – IETF coordination group – specifications of the control attributes for the individual IEEE 802 technologies by their working groups • Should go into annex of related specifications to ensure consistency 5

omniran-13 -0056 -00 -ecsg Tribute to ITU Network Protocol Specification in 3 Stages • For the specification of the Integrated Services Digital Network the ITU-T defined in its Rec. I. 130 a sequential 3 stage process, each leading to a separate standards document. • The same process is nowadays commonly applied by all telecommunication network standardization activities. Specify requirements from the user's perspective; Develop a logical/functional model to meet those requirements; Develop a detailed specification of the protocols and attributes. More Information: ETSI: Making Better Standards http: //docbox. etsi. org/MTS/10 -Promotional. Material/MBS-20111118/protocol. Standards/staged. Approach. htm 6

omniran-13 -0056 -00 -ecsg Applying the same approach to IEEE 802 • Direct evaluation of IEEE 802 protocols out of service/deployment requirements is challenging. ‘External’ requirements from the service/deployment perspective ? Develop a logical/functional model for evaluation of? those requirements; Available IEEE 802 specifications of protocols and attributes. • A Stage 2 specification provides a mapping of protocols into a functional network model, which facilitates easier evaluation. 7

omniran-13 -0056 -00 -ecsg Omni. RAN EC SG Proposal • Develop a kind of ‘Stage 2’ document for IEEE 802 network protocol specifications – Actually re-engineering a ‘Stage 2’ to make it fitting to the existing IEEE 802 network protocol specifications (which represent ‘Stage 3’). • Such specification makes it much more easy to evaluate and qualify ‘service’ requirements, – and provide a common framework for further enhancements of IEEE 802 protocols • It is a proven process by several other SDOs addressing network specifications • There is a well-defined understanding what should go into such a document 8

omniran-13 -0056 -00 -ecsg FYI: Usual ‘Stage 2’ Content ITU-T Rec I. 130 Wi. MAX Forum Stage 2 To. C • Derivation of a functional model • Information flow diagram • SDL diagrams for functional entities (optional) • Functional entity actions • Allocation of functional entities to physical locations • Introduction and Scope • Abbreviations, Definitions, and Conventions • References • Identifiers • Tenets • Network Reference Model • Functional Design and Decomposition Reference: http: //resources. wimaxforum. org/sites/wimaxforu m. org/files/technical_document/2010/12/WMFT 32 -001 -R 016 v 01_Network-Stage 2 -Base. pdf 9

omniran-13 -0056 -00 -ecsg Omni. RAN EC SG Conclusion • We should try to develop a PAR and 5 C for an IEEE 802 Recommended Practice – Similar to a Stage 2 specification – Potential title: ‘Network Reference Model and Functional Description of IEEE 802 based Access Networks’ – Leaving organizational questions open focusing only on the content of the PAR and 5 C? – Identifying gaps to existing IEEE 802 technologies and communicating them to the related working groups 10

omniran-13 -0056 -00 -ecsg Annex BACKGROUND INFORMATION MATERIAL 11

omniran-13 -0056 -00 -ecsg Omni. RAN allows for mapping of complex IEEE 802 network infrastructures Terminal R 2 Ctrl Access R 3 R 1 R 4 Internet R 3 Access R 3 Ctrl Core Authentication Authorization Accounting Location Co. A Mobility R 5 Access R 3 Encapsulation Data. Path Encapsulation Transport Internet • Reference Points represent a bundle of functions between peer entities - Similar to real network interfaces • Functions are extensible but based on IEEE 802 specific attributes 12

omniran-13 -0056 -00 -ecsg Access Network Control Plane Functions Access Network Scanning ANQP AAA DHCP Policy Configuration Application Network Selection Association Authentication Authorization Accounting Host Configuration Application Policy Control Application Host Config Release Disassociation Accounting Legend: L 2 Protocol L 2 Attributes L 2 Protocol L 3+ Attributes L 3+ Protocol L 2 Attributes L 3+ Protocol L 3+ Attributes 13

omniran-13 -0056 -00 -ecsg Control Plane Functions in Scope of IETF Access Network Scanning ANQP AAA DHCP Policy Configuration Application Network Selection Association Authentication Authorization Accounting Host Configuration Application Policy Control Application Host Config Release Disassociation Accounting Legend: L 2 Protocol L 2 Attributes L 2 Protocol L 3+ Attributes L 3+ Protocol L 2 Attributes L 3+ Protocol L 3+ Attributes 14

omniran-13 -0056 -00 -ecsg Mapping of Omni. RAN Reference Points to IEEE 802 Reference Model Higher Layers Control R 2 Data Link Physical R 1 Medium Higher Layers Control R 3 Data Link Physical Medium Data Link Physical Medium Current scope of IEEE 802 • Reference Points can be mapped onto the IEEE 802 Reference Model – R 1 represents the PHY and MAC layer functions between terminal and base station • Completely covered by IEEE 802 specifications – R 2 represents the L 2 control protocol functions between terminal and central entities for control and AAA. – R 3 represents the L 1 & L 2 control interface from a central control entity into the network elements • ‘R 2’ and ‘R 3’ cover IEEE 802 specific attributes – However IP based protocols are used to carry control information between network elements and core – Effectively each of IEEE 802 network elements contains an IP communication stack on top of the IEEE 802 data path for the exchange of the control information. 15