IEEE 802.11bd vs. OCB Architecture Discussion
Explore the impact of IEEE 802.11bd on the OCB architecture, highlighting the lack of significant changes in 802.11 BSSs and authentication services. Discover insights into NGV STAs and their support for ITS applications. Dive into proposed clean-up efforts for the MAC service interface in alignment with higher layer standards.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
November 2020 doc.: IEEE 802.11-20/1166r4 NGV 11bd Architecture Discussion Date: 2020-11-03 Authors: Name Joseph LEVY Affiliations InterDigital Communication, Inc. Address 111 W 33rd Street New York, NY 10120 Phone +1.631.622.4139 email joseph.levy@interdigital.com Submission Slide 1 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Abstract This submission provides the view of 802.11 TGbd that the 802.11bd amendment will not impact the 802.11 architecture. For discussion purposes information is provided regarding the proposed NGV MAC service update. r0: was reviewed during the 4 August TGbd teleconference r1: updated based on comments made during 4 August TGbd teleconference r2: added some additional information on the clean up the MAC service interface (slides 5, 6, 7). This new content needs review and may be updated. r3: updated slides 5 and 6 (slide 6 is new and is a continuation of the old slide 5) to align with Draft P802.11bd D1.0. r4: typo corrections. Submission Slide 2 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Architecture of OCB (.11p) OCB is defined as [1]: outside the context of a basic service set (BSS) (OCB): A mode of operation in which a station (STA) is not a member of a BSS and does not utilize IEEE 802.11 authentication, association, or data confidentiality services. STA behaviour OCB is summarized in Clause 4.3.7 [1]: The 802.11 architecture of STAs using OCB is a simple transmit and receive architecture There is no network in the 802.11 OCB architecture, only STA to STA (point to point) or STA to STAs (broadcast) communication over the wireless media. No 802.11 MAC sublayer authentication services are used. OCB STAs can support ITS applications, providing IEEE 1609 or other higher layer standards communication services over the wireless media. There are currently no architecture figures related to OCB in 802.11 [1] Submission Slide 3 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Architecture of NGV (.11bd) Thoughts There are no planned changes to the OCB concept, hence: There are no 802.11 BSSs in NGV There is no 802.11 authentication, 802.11 association, or 802.11 data confidentiality services in NGV There is no planned changes to the STA behaviour OCB (Clause 4.3.7): So there are no significant 802.11 architecture impacts NGV STAs operating in a OCB mode are targeted to support ITS applications NGV STAs will provide IEEE 1609 or other higher layer standards next generation communication services over the wireless media. There are currently no architecture figures proposed to be added to the 802.11 specification Submission Slide 4 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Possibly of Interest to the 802.11 ARC SC There is a proposal to clean up the MAC service interface so that it is more compatible with IEEE 1609 and other higher layer ITS specifications In Clause 5 [6]: A new parameter was added to MA-UNITDATA.request and MA-UNITDAT.indication: radio environment request vector The Radio Environment Request Vector contains the following elements: PPDU format (legacy/NGV), data rate/MCS for transmission, number of spatial streams, permitted aggregation, number of repetitions, expiry time (milliseconds until the MSDU is discarded if still not transmitted), frequency band, primary channel, channel width, fallback enabled, transmit power level A new entity was added: Radio Environment Report. Which defines the MA- RADIOENVIRNMENT.indication with the following parameters: channel busy percentage, capability percentage, and station count. Submission Slide 5 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Possibly of Interest to the 802.11 ARC SC (cont.) In Clause 6 [6] the following primitives were added: MLME-CANCELTX.request - allows the SME to cancel transmission of MSDUs that are currently in the MAC transmit queue MLME-CANCELTX.confirm notifies the SME that MSDUs of a specified access category have been removed from the transmit queue (as per the request). Submission Slide 6 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 NGV Higher Layer Control Proposed Architecture Proposed Architecture 1609/802.11 Each 802.11 STA has a MAC and a PHY that operates on a specific channel. The MPDUs to be sent on that channel are provided to the specific MAC SAP by the 1609 Channel Routing facility. MPDUs received by the PHY on that channel are passed up to the 1609 Channel Routing facility. 1609 Channel Routing This is a MAC/PHY pair each MAC/PHY pair is an instance of what is specified by 802.11. Note: Each 802.11 MAC entity, contains AC queues and independently manages MPDU priority queueing, and transfer to its associated PHY layer. Also note that while only two 802.11 MAC/PHY entity pairs are shown, additional channels could be supported by addition MAC/PHY entity pairs, there is no requirement to limit this to two pairs. 802.11 MAC 802.11 MAC Therefore, the 802.11 specification need only provide specification for a single MAC/PHY pair, as it currently does and all multi-channel operation is a function of 1609, so any queue flushing is per channel and there is no need to specify in 802.11 channel information as the command is only sent to one MAC entity. Also any discussion of 1609's capabilities to use multiple channels in the 802.11 specification would only be informative, as all multiple channel capabilities would be specified in 1609 specifications. 802.11 PHY (single RF channel) 802.11 PHY (single RF channel) Submission Slide 7 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 Current IEEE 1609 Architecture Figure [5] [5] page 17, clause 5.1 Submission Slide 8 Joseph Levy (InterDigital)
November 2020 doc.: IEEE 802.11-20/1166r4 References 1. IEEE 802.11REVmdD3.0, http://www.ieee802.org/11/private/Draft_Standards/11md/Draft%20P802.11REVmd_D3.0.pdf 11-19/1805r1 MAC Service Update for NGV, Michael Fischer 11-19/1031r0 The MAC Services Mismatch Between 802.11 and 1609.4, Michael Fischer 11-19/0083r5 Indicating NGV Capabilities in MAC Header, Michael Fischer IEEE Std 1609.4-2010, IEEE P802.11bdD1.0 Draft Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications Amendment 5: Enhancements for Next Generation Vehicular Communication 2. 3. 4. 5. 6. Submission Slide 9 Joseph Levy (InterDigital)
