camden
Uploaded by
14 SLIDES
279 VUES
140LIKES

Requirements for MAC / PHY Simulation Interface

DESCRIPTION

This presentation reviews the PHY services specified in Clause 12 of the 802.11 specification and highlights the importance of accurate modeling for MAC/PHY interface in simulation. It addresses potential impacts of inappropriate PHY modeling on system simulation results and provides requirements for PHY service primitives used in simulators. Key services such as PHY-DATA, PHY-TXSTART, PHY-RXSTART, among others, are discussed. The proposal ensures compatibility with different PHY abstraction methods and emphasizes the need for correct carrier sensing for effective coexistence in legacy and mixed-mode scenarios.

1 / 14

Télécharger la présentation

Requirements for MAC / PHY Simulation Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements for MAC / PHY Simulation Interface Masahiro TAKAGI takagi@csl.rdc.toshiba.co.jp TOSHIBA Darren McNamara Darren.McNamara@toshiba-trel.com TREL Masahiro TAKAGI, Toshiba

  2. Overview • The PHY services provided to the 802.11 MAC are specified in Clause 12 of the 802.11 specification [1]. • Inappropriate modeling of the PHY services would affect the results of system simulations. PHY services should be properly modeled in the simulators. • This presentation reviews the current PHY service specification and proposes the requirements for MAC / PHY interface of the simulators. • This proposal is independent of whichever PHY abstraction method is chosen. Masahiro TAKAGI, Toshiba

  3. 802.11 Protocol Reference Model • The PLCP (Physical Layer Convergence Protocol) sublayer hides the PMD (Physical Medium Dependent) sublayer from the MAC, and provides PHY-independent services to the MAC through the PHY-SAP. Masahiro TAKAGI, Toshiba

  4. List of PHY service primitives Masahiro TAKAGI, Toshiba

  5. PHY-DATA • PHY-DATA is used when the MAC transmits or receives an octet of data to or from the PHY. • Simulators may use a frame level data transfer model between the MAC and PHY, so this octet level data transfer behavior can be safely ignored. Masahiro TAKAGI, Toshiba

  6. PHY-TXSTART • PHY-TXSTART is used when the MAC requests the PHY to transmit a frame. TXVECTOR specifies the parameters (Rate, Length, etc.) to be used in the transmission. • TXVECTOR parameter may contain any PHY dependent information which is defined in the relevant specifications (proposal or existing standard). • The simulator may use PHY dependent parameters in addition to Rate and Length when the MAC requests the PHY to transmit a frame. Masahiro TAKAGI, Toshiba

  7. PHY-TXEND • PHY-TXEND terminates transmission prematurely. • Simulations may safely ignore this service. Masahiro TAKAGI, Toshiba

  8. PHY-RXSTART • PHY-RXSTART is used when the PHY notifies the MAC of the start of a frame reception. RXVECTOR specifies the parameters (Rate, Length, etc.) for the frame reception. • RXVECTOR parameter may contain any PHY dependent information which is defined in the relevant specifications (proposal or existing standard). • The simulator may use PHY dependent parameters in addition to Rate and Length when the PHY notifies the MAC of frame reception. Masahiro TAKAGI, Toshiba

  9. PHY-RXEND • Normal frame reception (PHY-RXEND.indication (NoError) with correct FCS) triggers several events at the MAC. • A frame reception with errors triggers an EIFS at the MAC in the following cases: • PHY-RXEND.indication (NoError) and FCS check fail at the MAC. • PHY-RXEND.indication (FormatViolation, CarrierLost or UnsupportedRate) • This service is covered by the existing discussions on PHY abstraction by the SMSC, as only a ‘Reception successful or unsuccessful’ notification is required by simulation. Masahiro TAKAGI, Toshiba

  10. PHY-CCA • The MAC uses PHY-CCA to determine if the PHY carrier sense state is idle or busy. • A simulator should consider all the PHY carrier sense methods (energy, preamble etc.) when determining the setting of PHY-CCA. • The carrier sense sensitivity level should be appropriately adjusted according to the conditions specified in the relevant proposal or standard. • PHY-CCA shall stay in the busy state for the frame duration once this value is determined from the information contained in the PLCP header. Masahiro TAKAGI, Toshiba

  11. PHY-CCARESET • PHY-CCARESET is used when the NAV is reset. • A simulator should set the PHY carrier sense state to idle if the NAV is reset. Masahiro TAKAGI, Toshiba

  12. PHY-CCA for Coexistence • Usage models [2] include scenarios for legacy coexistence evaluation • Scenario 9 (Mixed-Mode BSS) (Mandatory) • Scenario 11 (Co-channel legacy BSS) (Mandatory) • Scenario 19 (Point-to-Point Legacy Sharing Throughput Test for CC 15 (Mandatory) • CCA is the primary MAC deferral mechanism • If proposals include a non backwards compatible PLCP preamble and header for HT operation, this should affect the CCA sensitivity threshold used during reception by legacy STAs [1]. • Calculation of RX power and knowledge of PLCP compatibility is part of the PHY abstraction, and therefore the state of PHY-CCA should be reported by the PHY abstraction. Masahiro TAKAGI, Toshiba

  13. Conclusion • Most of the PHY services which would affect simulation results have already been considered in the SMSC. • CCA at legacy STA should not be overlooked, since it would affect the results of mixed-mode and legacy coexistence scenarios. • PHY-CCA needs to be determined and reported by the PHY abstraction. Masahiro TAKAGI, Toshiba

  14. References • [1] IEEE Wireless LAN Edition -A compilation based on IEEE Std 802.11TM-1999 (R2003) and its amendments- • [2] Usage Models (11-03/802r12 ) Masahiro TAKAGI, Toshiba

More Related