1 / 26

1609.3/4 Items

1609.3/4 Items. Malarky/Moring for 1609 WG Meeting Feb 2 2010. Issues & Solutions. Access to 802.11 frames 1609.4 Scope etc WME-RCPIRequest TPC vs RCPI Request Best Available Channel Management ID vs OI in MLMEX-VSA Availability of Vendor Specific Info Other. 1. Access to 802.11 frames.

zacharee-horn
Download Presentation

1609.3/4 Items

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. 1609.3/4 Items Malarky/Moring for 1609 WG Meeting Feb 2 2010

  2. Issues & Solutions • Access to 802.11 frames • 1609.4 Scope etc • WME-RCPIRequest • TPC vs RCPI Request • Best Available Channel • Management ID vs OI in MLMEX-VSA • Availability of Vendor Specific Info • Other

  3. 1. Access to 802.11 frames • Add WME-SendMlmePrimitve.req • Includes contents of “any” (?) 802.11 MLME primitive, plus • Channel Identifier (Channel Number, Regulatory Class) • Channel Interval? • Other? • WME schedules request and sends new MLMEX-SendMlmePrimitve.req (and MLMEX-StartSCH.req if necessary) • 1609.4 MLME (changes channel if necessary) • And sends the designated MLME-….req • 802.11 processes MAC data normally on tx and rx • Addresses perceived need to support link management frames • MLME-MEASURE.req, MLME-MREQUEST.req, MLME-LINKMEASURE.req • And maybe MLME-MREPORT.req • 1609 Tx side processing only; Rx handled by 802.11 • Must address throughout 1609.3 where request processing

  4. 2. 1609.4 Scope etc • Dick: • “The scope of this standard is to define services and functionality in the data link layer, and more specifically in the MAC sublayer, to support multi-channel wireless connectivity among devices using the 5.9 GHz MAC & PHY specified in IEEE 802.11.” • Alastair (using tailoring of 1609.3 language): • “The scope of this standard is to define services, in particular services for multi-channel operation, operating at the medium access control (MAC) layer, in support of wireless connectivity among vehicle-based devices, and between roadside devices and vehicle-based devices using the 5.9 GHz DSRC/WAVE mode.”

  5. 3. WME-RCPIRequest • Current RCPI processing replaced with solution described under #1.

  6. 4. TPC vs RCPI Request • Transmit Power Control (TCP) monitoring supported by solution described in #1.

  7. 5. Best Available Channel • Agreed to remove references to this feature as misleading. May be reinstated in future versions after further definition.

  8. 6. Management ID vs OI in MLMEX-VSA • Allow identification of external management entity by Organization Identifier (in addition to current Management ID) • Extension to existing WME-ManagementDataService.req and MLMEX-VSA.req • 1609 Tx side processing only; Rx handled by 802.11

  9. 7. Availability of Vendor Specific Info • Add ability of external management entities to append Vendor Specific data (VSIE) to general 802.11 management frames • Supported by solution described under #1

  10. 8. Comment 1609.4/Malarky-29 • Comment: the requirement "A WAVE device that is not synchronized to UTC shall not transmit Timing Advertisement frames" … is overly restrictive and in-appropriate • Solution: "A WAVE device that is not synchronized to UTC shall not transmit Timing Advertisement frames to the broadcast MAC address." • The achieves the objective of protecting from flooding while allowing query-response timing for, e.g., security synchronization

  11. Original Presentation Follows

  12. Access to 802.11 Frames • To date it has been assumed that higher layers and extensions to 1609 (.3 or .4) can invoke other 802.11 frames to provide additional functions beyond those specified in 1609.3 & 1609.4. • However because the current RF channel is managed by 1609.4, there is no (documented) way for any higher layer to control on what channel the 802.11 frame is transmitted on using the SAP definitions in the current 1609.4 & 802.11(+p) standards. • I believe we need to address this issue.

  13. Access to 802.11 Frames (cont) • I do not believe it to be appropriate for the higher layers to define MAC primitives • E.g. App wants to use 802.11 “Link Measure” – this is MLME request • This should be handled by invoking 1609.4 primitives – MLMEX • The reason we need to create a set of MLMEX primitives is because we need to pass additional information beyond that used by the 802.11 primitives : • Channel Identifier • Channel Interval • Repeat Rate • Note Repeat Rate and Channel Interval are really for convenience in creating repeats. The only real driving reason is because we have to define the channel.

  14. Access to 802.11 Frames (cont) • We also need to supply transmit power to the PHY via MLME. • Not addressed in 1609.4 for following cases: • WME-RCPIRequest.request • WME-TimingAdvertisementService.request • MLMEX-TA.request • MLMEX-VSA.request • Another reason for MLMEX primitives definitions in 1609.4 for these

  15. Access to 802.11 Frames (cont) • It is not all the 802.11 SAP primitives • Some are not applicable since these apply to frames only accessible in IBSS/BSS only • Some are not channel specific (e.g. MLME-RESET, MLME-GETTSFTIME) • Generally only request primitives affected in most cases. • I recommend that 1609.4 provides MLMEX-<xxx> primitives for 802.11 primitives usable in OCB that need the channel and power defined. • Channel Identifier and transmit power could be optional parameters and default to CCH values maintained by WME. • Could be as simple as a generic statement stating MLMEX primitives are MLME primitives with the additional parameters. .

  16. Access to 802.11 Frames (cont) • For example (list is not complete) 1609.4 should provide MLMEX primitives for: • MLME-GETTSFTIME – already done • MLME-LINKMEASURE • MLME-MREQUEST • MLME-TIMING_ADVERTISEMENT – already done • MLME-START– already done • MLME-VSPECIFIC – already done

  17. Access to 802.11 Frames (cont) • Do we need WME- versions for higher layer access • Only reason is if parameter list is different or parameters are not available at higher layer: • Allow IPv6 address to be used • Hide Dialog Token in MREQUEST • Probably need WME versions in some cases. • Still don’t need to reduce to single function like WME-RCPIRequest.request. • E.g. could be WME-MREQUEST.request and achieve the broader availability of 802.11 functions.

  18. 1609.4 Scope etc • Response to 1609.4 Malarky/09 confirms that 1609.4 in conjunction with 802.11(+p) defines the WAVE MAC. This is not reflected in scope or purpose. • Higher layers in a single channel WAVE implementation both management and data still have to pass through 1609.4 SAPs – it is not limited to “multi-channel” • 1609.4 Malarky/28 was raised to reflect this.

  19. WME-RCPIRequest • In 1609.3 the WME-RCPIRequest.request results in the WME invoking MLME-MREQUEST.request without : • addressing the need to set channel in MLME • not provided by MLME-MREQUEST.request • addressing the transmit power to be used • Not provided in WME-RCPIRequest .request • Not provided in MLME-MREQUEST.request • Making VSIE available • WME-RCPIRequest.request should invoke MLMEX-MREQUEST.request • Should include transmit power and Channel Identifier and all of MLME-MREQUEST.request parameters. .

  20. TPC vs RCPI Request • We currently have defined in 1609.3 the primitives WME-RCPIRequest.request and WME-RCPIReport.indication to support link quality evaluation. • 802.11 provides another useful set of element for this purpose: • TPC Request / Report accessible via MLME-MREQUEST • Link Measurement Request/ Report • 802.11 also provides another set of primitives useful to obtain data on current STA • MLME-MEASURE

  21. TPC vs RCPI Request (cont) • Recommend: • Provide MLMEX versions of key 802.11 primitives in 1609.4 as requested earlier • Refer to these from 1609.3. • Replace WME-RCPIRequest with WME-REQUEST • Indicate can be used for RCPI, TPC, Link measure ..

  22. Best Available • In 1609.3_D2, the concept of a “best available” channel was introduced into: • MLMEX-SCHSTART.request • WME-ProviderService.request • Service channel quality evaluation • However such a feature conflicts with the regulatory limitations on use of channel(s) which are tied to: • The operator/owner of the equipment • The information carried in the payload of data messages • The WME has no means to determine which channels the application is eligible to use in order to make its selection of the “best available” channel.

  23. Best Available Issue (cont) • Recommend either : • remove this feature; or • add in functionality that the application can define to the WME what channels it is eligible to transmit on.

  24. Management ID vs Organization Identity in MLMEX-VSA • The reason we need to create a set of MLMEX primitives for VSAs is because we need to pass additional information beyond that used by the 802.11 primitive for VSAs: • Repeat Rate • Channel Identifier • Channel Interval • Note Repeat Rate and Channel Interval are really for convenience in creating repeats. The only real driving reason is because we have to define the channel. • The VSA frame contains the Organization Identifier (defined by 802.11p) • In the MLMEX-VSA.request & .indication, we pass: • Management ID; and • Vendor Specific Content • The 1609.4 implementation is required to create the 1609.x Organization Identifier in the subsequent frame(s).

  25. Management ID vs Organization Identity in MLMEX-VSA • Because of this definition we appear to limit the use of the MLMEX-VSA primitives to only 1609 entities. • However this also means that any higher level management entities operating with 1609 must define their own MAC extension because they too will need to add Channel Identifier and transmit power • I recommend that the MLMEX-VSA primitives be modified to pass Organization Identifier instead of Management ID.

  26. Availability of Vendor Specific Info • For WME-RCPIRequest and WME-RCPIReport, we provide no means to pass a VSIE in the frame, despite this being supported by 802.11 in MLME-MREQUEST.<xxx> • Whether or not we have defined functionality in 1609.3 and 1609.4 to use the VSIE – we should provide the means to add and receive the VSIE • A separate discussion relates to TA frame.

More Related