Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 1 Requirements for MAC / PHY Simulation Interface Masahiro TAKAGI

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 1 Requirements for MAC / PHY Simulation Interface Masahiro TAKAGI"— Presentation transcript:

1 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 1 Requirements for MAC / PHY Simulation Interface Masahiro TAKAGI takagi@csl.rdc.toshiba.co.jp TOSHIBA Darren McNamara Darren.McNamara@toshiba-trel.com TREL

2 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

3 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

4 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 4 List of PHY service primitives primitive nameflowparametervaluedescription PHY_TXSTART.requestMAC→PHYTXVECTORPHY dependstart the transmission of an MPDU PHY_TXSTART.confirmPHY→MACnoN.A.response to PHY_TXSTART.request PHY_TXEND.requestMAC→PHYnoN.A.receive the last PHY_DATA.comfirm PHY_TXEND.confirmPHY→MACnoN.A.response to PHY_TXEND.request PHY_DATA.requestMAC→PHYDATAX'00'-X'FF' (Octet)transfer of an octet of data PHY_DATA.confirmPHY→MACnoN.A.confirmation of PHY_DATA.request PHY_DATA.indicationPHY→MACDATAX'00'-X'FF' (Octet)transfer of an octet of data PHY_RXSTART.indicationPHY→MACRXVECTORPHY dependreceive valid PLCP Header PHY_RXEND.indicationPHY→MACRXERRORNoError/ completed a reception with or without errors FormatViolation/ CarrierLost/ UnSupportedRate PHY_CCARESET.requestMAC→PHYnoN.A.the end of a NAV timer. PHY_CCARESET.confirmPHY→MACnoN.A.response to PHY_CCARESET.request PHY_CCA.indicationPHY→MACSTATUSBUSY/IDLEreport of channel state change

5 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

6 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

7 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 7 PHY-TXEND PHY-TXEND terminates transmission prematurely. Simulations may safely ignore this service.

8 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

9 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

10 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

11 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

12 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

13 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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.

14 doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 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 )


Download ppt "Doc.: IEEE 802.11-04/219r0 Submission Mar 2004 Masahiro TAKAGI, ToshibaSlide 1 Requirements for MAC / PHY Simulation Interface Masahiro TAKAGI"

Similar presentations


Ads by Google