1 / 63

August 2009 John Moring

August 2009 John Moring. Use of the Timing Advertisement frame in WAVE. Questions on timing info in the TA frame. TA processing in general What devices may transmit it? When is it transmitted? On what channel(s) is it transmitted? Under what conditions is it accepted and used?

wilona
Download Presentation

August 2009 John Moring

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. August 2009John Moring Use of the Timing Advertisement frame in WAVE

  2. Questions on timing info in the TA frame • TA processing in general • What devices may transmit it? • When is it transmitted? • On what channel(s) is it transmitted? • Under what conditions is it accepted and used? • 802.11 addresses these questions in the context of BSS, but this does not apply to WAVE • These questions should be addressed in 802.11p, but are not • How does distribution of regulatory info in the TA frame relate to the distribution of timing info?

  3. Questions on regulatory info in the TA frame • Is 1609 responsible for distributing regulatory info (band plan, power constraints)? If so, how do we do it…? • Is 1609 responsible for processing regulatory info received over the air? • Can’t rely on 802.11 which assumes BSS context • What should 1609 do with received band plan info? • 1609 manages power in Tx Profiles and WSMs • Use of received vs. configured vs. specified limits; how to handle conflicts • How to interpret “local” power constraint? • Defined in 802.11 in the context of an Access Point • What do we do about Coverage Class? • Not currently usable in WAVE because it can’t be set per channel

  4. Other questions • What does WAVE do with the capabilities info in the TA frame? • What security is associated with timing advertisement? • Do we need a time request message? • Of what form? How is it used? • Perhaps also regulatory request message?

  5. Summary of recommendations • Suggest WAVE uses only the timing info of the Timing Advertisement • Not capabilities or regulatory info • WAVE allows distribution of TA on any channel in SCH and/or CCH Intervals • Suggest WAVE support alternate method for regulatory info distribution • Either in the WSA, or • In a new Vendor Specific Action message

  6. Outline • Time alignment and channel switching in WAVE • Timing Advertisement frame contents per 802.11p • Capabilities info • Use for timing distribution and time alignment • Regulatory info distribution, subband usage, and transmit power control • Security • Changes to the WSA format • Summary

  7. Time alignment in WAVE • Assumptions • Some devices may need to switch channels on channel interval boundaries to participate in multiple services • Some devices base security verification of received messages on knowledge of time • Some of these same devices may not have a local absolute timing source • Conclusion: WAVE must provide an over-the-air time synchronization option with better than 1 ms accuracy • Approach • Designated devices periodically transmit timing information • Receiving devices may derive time sync adequate for switching within the guard intervals occurring on channel interval boundaries

  8. Time sync – Trial Use • Channel intervals aligned with UTC second boundaries • Timing information distributed with WSAs, in WAVE Announcement frame • 802.11p • Timestamp: TSF timer (in µs) of transmitter at transmit time • Local Time: TSF Timer (in µs) of receiver at receive time • 1609.4 • Timing Capabilities of transmitter • TSF Timer Offset: difference (in µs) between transmitter's TSF timer and UTC • TSF Timer Standard Deviation: error estimate of TSF Timer Offset • 1609.3 • Verifies credentials of WSA before receiving device accepts timing info • Service Provider is timing source

  9. TSF TSF UTC Trial Use flow of timing information (in WSA) • TSF Timer is the unit’s internal clock, used to determine SCH & CCH intervals • Distribution of TSF time allows units without GPS to synchronize channel switching PROVIDER Build and sign WSA USER Verify and process WSA MLME-GETUCTTIME.req WME WME Add Local Time MLME MAC MAC MLME • Add timing info • Timing capabilities • TSF timer offset • TSF timer std dev AFTER VERIFICATION Process time info; adjust TSF Add TSF timestamp PHY PHY UTC offset “WAVE Advertisement” frame

  10. Time sync – current drafts • Channel intervals aligned with UTC second boundaries • Timing information distributed separate from WSAs, in Timing Advertisement frame • Defined and set in 802.11p D8.0 • Timestamp: TSF timer (in µs) of transmitter at transmit time • Local Time: TSF Timer (in µs) of receiver at receive time • Defined in 802.11p, set in 1609.4 • Timing Capabilities of transmitter • TSF Timer Offset Estimate: difference (in ns) between transmitter's TSF timer and UTC • TSF Timer Standard Deviation: error estimate of TSF Timer Offset • “Other info” - additional fields such as Country and Capability • No assumption on what devices may be timing sources • Except they must have a local time source per 802.11p

  11. TSF TSF UTC Current draft flow of timing information • Note, associated security processing not defined • TSF timer free-runs; UTC estimate is used for channel switch synchronization Timing provider Timing user MLMEX-TA.ind MLMEX-GETUCTTIME.req MLMEX-TA.req Add Local Time MLME MAC MAC MLME • Add timing info • Timing capabilities • TSF timer offset • TSF timer std dev Add Timestamp Process time info; adjust UTC estimate UTC estimate PHY PHY “Timing Advertisement” (TA) frame

  12. 1609.4 MLME controls channel switching on interval boundaries

  13. GET UTC TIME • 1609 MLME also provides time to external entities on request MLMEX-GETUTCTIME.confirm( ResultCode, Timestamp, Time Value, Time Error ) • Timestamp is the device internal counter • Time Value is the estimated offset to UTC time • Time Error is the estimated error in Time Value • Could be used by applications or security processing

  14. Outline • Time alignment and channel switching in WAVE • Timing Advertisement frame contents per 802.11p • Capabilities info • Use for timing distribution and time alignment • Use for regulatory info distribution, subband usage, and transmit power control • Security • Summary

  15. Timing Advertisement frame in 802.11p

  16. Timestamp and Time Advertisement discussed in context of timing Country and Power Constraint discussed in context of regulatory info Vendor Specific info discussed in context of security Capability and Extended Capabilities discussed separately Only Timestamp is populated by 802.11; others are set by 1609 TA frame contents summary

  17. Contains three fields as shown below Timing Capabilities=0 could be used by devices sending regulatory info, but not timing info However, we do not intend to use this feature But we have no way to send timing info without also sending regulatory info Time Advertisement element • 1609.4 sets Time Value and Time Error as described in 802.11p

  18. TA frame details and usage

  19. Suggestions for 802.11p • In 802.11p D8.0, TA frame contains fields unused in WAVE • Mandatory: Capability, Country • Optional: Power Constraint, Extended Capabilities • “One or more” Vendor specific info elements “may appear” • Assume this means optional • 802.11p does not specify how these fields are used outside the context of a BSS (i.e., in WAVE) • 802.11 specifies them, but assumes non-WAVE operation • Suggest that Capability and Country be made OPTIONAL • Vendor specific info should also be explicitly OPTIONAL

  20. Relevant MIB attributes • dot11OCBEnabled (= TRUE per 802.11p) • dot11MultiDomainCapabilityEnabled (= TRUE per 802.11p) • dot11MultiDomainCapabilityImplemented • dot11RegulatoryClassesRequired (= TRUE per 802.11p) • dot11RegulatoryClassesImplemented • dot11SpectrumManagementRequired (= TRUE per 802.11p) • dot11SpectrumManagementImplemented • dot11CountryString • dot11RegulatoryClassesTable, list of • dot11RegulatoryClass • dot11CoverageClass • dot11MultiDomainCapabilityTable, list of • dot11FirstChannelNumber • dot11NumberofChannels • dot11MaximumTransmitPowerLevel • dot11StationClass, A/B/C/D added by 802.11p • Not used in favor of CountryString/RegulatoryClasses • dot11RegDomainsSupported • FCC, DOC (Canada), ETSI, Spain, France, Japan, China, Other • dot11CurrentRegDomain • dot11FrequencyBandsSupported • dot11CurrentFrequency – definition does not support 5.9 GHz operation

  21. Outline • Time alignment and channel switching in WAVE • The Timing Advertisement frame contents per 802.11p • Capabilities info • Use for timing distribution and time alignment • Use for regulatory info distribution, subband usage, and transmit power control • Security • Summary

  22. Capability element • Mandatory in the TA frame per 802.11p • AKA Capability Information • Lots of requirements in 802.11 for BSS/IBSS operation, none in 802.11p • Does not seem to have any value in WAVE • Proposal: • Transmitting 1609.4 will set as shown following • Receiving 1609.4 will ignore

  23. Capability details

  24. Extended Capabilities element • Optional in the TA frame • There are no extended capabilities defined in 802.11-2007 • There are no extended capabilities defined in 802.11p • I find no applicable extended capabilities in other recent work • 802.11n/y/z • Proposal: not used by WAVE

  25. Outline • Time alignment and channel switching in WAVE • The Timing Advertisement frame contents per 802.11p • Capabilities info • Use of TA for timing distribution and time alignment • Use of TA for regulatory info distribution, subband usage, and transmit power control • Security • Summary

  26. Mechanics of sending the TA frame in 1609 • Requesting entity provides scheduling info • Rate • Duration • Channel Number • Channel Interval • ServicePriority • 1609.3: • Schedules the TA service, in possible competition with other service requests • 1609.4 • Performs channel switching if required to visit the TA channel • Generates periodic MLME-TIMING_ADVERTISEMENT.req • Populates Time Advertisement/Timing Capabilities info element • Verifies a timing source is present, populates Time Value and Time Error • Populates Country per MIB

  27. Note on TA request in 1609.3 • D1.2 of 1609.3/1609.4 assume TA is triggered by a request from an unspecified entity external to 1609.4 • Bypasses 1609.3 • In future drafts, request will go through 1609.3 so it can be evaluated by the channel scheduling algorithm • TA request allows TA on any channel, so WME must schedule access based on available resources and request priorities

  28. Timing message flow - objective

  29. Timing Advertisement through the layers • 1609.4 calculates and transmits periodically • On request • On receipt, 1609.4 updates local UTC time estimate… • On what conditions? • Local configuration • Security • Time quality • Other updates received

  30. TA primitives WME-TA.request ( Action, Rate, Duration, Channel Number, Channel Interval, ServicePriority ) No WME processing or indication primitive defined. • 1609.3 • 1609.3 • MLMEX-TA.request ( • Rate, • Channel Number, • Channel Interval • ) MLMEX-TA.indication( RCPI, Source MAC address ) • 1609.4 • 1609.4 • MLME-TIMING_ADVERTISEMENT.indication( • Timestamp, • Local Time, • Capability Information, • Time Advertisement, • Country, • Power Constraint, • RCPI, • Source MAC address, • Extended Capabilities • VendorSpecificInfo • ) MLME-TIMING_ADVERTISEMENT.request( Capability Information, Time Advertisement, Country, Power Constraint, Extended Capabilities, VendorSpecificInfo ) • 802.11p • 802.11p

  31. Received Channel Power Indicator • RCPI was added to the 802.11p MLME-TIMING_ADVERTISEMENT.indication at the request of 1609 for use in evaluating link quality • From the Provider, when TA frame was used for WSA • Now that we don’t use TA for WSA, we don’t need RCPI • 802.11p may remove it

  32. Receiving the TA frame in 1609 • 1609 does not specify any special channel scanning • If a WAVE device does not need timing, received TA frame is ignored • If a WAVE device does need timing, received TA frame is processed by 1609.4 • Capability/Extended Capabilities are ignored • Country • Country String is accepted per 802.11 • Regulatory Class is ignored • Channel List is ignored • These parameters are better distributed via other means • Power Constraint is ignored • This parameter is better distributed through the WSA • Time Advertisement/Timestamp are processed • Acceptance and use of timing info left to the implementation • Security TBD

  33. Outline • Time alignment and channel switching in WAVE • The Timing Advertisement frame contents per 802.11p • Capabilities info • Use for timing distribution and time alignment • Use for regulatory info distribution, subband usage, and transmit power control • Security • Summary

  34. 5.9GHz Regulatory Classes in 802.11p, Annex J USA Europe • Example: “Channel 172” could be any one of 6 distinct channels • Different center frequencies, bandwidths, and max tx power depending on regulatory domain • Country/Regulatory Class parameters provide the context • Configured in the MIB • May be distributed over the air • Specified in the 802.11p Timing Advertisement frame • As well as 802.11 Beacon, Probe Response (not used in WAVE)

  35. Multi-domain capability in 802.11 • 802.11p mandates that all WAVE devices be capable of operation in multiple regulatory domains • Per MIB dot11MultiDomainCapabilityEnabled=TRUE in 802.11p/Annex J • 802.11/9.8 describes “operation across regulatory domains and … supports cross-domain mobility and operation in multiple regulatory domains” • Multidomain capability includes use of the Country info element in certain management messages • Info about allowed channel sets and transmit power sent out periodically • Accepted by stations entering the domain • 802.11y/9.8 expands multi-domain description, but does not address WAVE • “STA shall indicate Current Regulatory Class information in the Country Information element ….” • “When a STA with dot11MultiDomainCapabilityEnabled set to true enters a regulatory domain, before transmitting, it shall passively scan to learn at least one valid channel ….”

  36. Assumptions/questions • Assumptions • A WAVE station only operates in one country at a time • STAs adopt the received Country String per 802.11/7.3.2.9 • Includes storing in the MIB • A WAVE device may be capable of multiple Regulatory Classes and multiple subbands within a Regulatory Class • A device may be concurrently active in multiple subbands of a Regulatory Class • The local context can be announced by some WAVE devices • The context could be distributed via the Timing Advertisement frame (as apparently envisioned by 802.11p) or by other means, e.g., WSA • Questions • Can multiple Regulatory Classes be active in a local area??? • Can a device be concurrently active in multiple Regulatory Classes???

  37. Regulatory info in TA frame, element definitions per 802.11 • Country • Required in TA frame for WAVE operation per 802.11p • Country String, e.g., “US ” (Mandatory) • Also indicates Indoor/Outdoor operation (e.g., “USO”/”USI”), if applicable • Regulatory extension (Mandatory per dot11RegulatoryClassesRequired set in 802.11p) • Not clear whether this may be repeated??? • Regulatory Class (identifies channel numbering plan) • Coverage Class (max BSS propagation time, used to adjust PHY slot time; usage not specified for WAVE) • Channel list; mandatory, may be repeated • First Channel Number (identifies the lower end of an operational subband) • Number of Channels (defines the extent of an operational subband) • Maximum Transmit Power Level – in dBm, no clear relationship to power levels in normative Annex J • Power Constraint(optional) • Reduces in the maximum transmit power for the current channel in the local area

  38. Country information element

  39. CountryString in 802.11 • Country String, per 802.11/7.3.2.9 • “The AP shall set this field to the value contained in the dot11CountryString attribute before transmission in a Beacon or Probe Response frame.” • Does not apply to WAVE. We do not have Access Points or their equivalent; there is no similar guidance for WAVE. • “Upon reception of this element, a STA shall set the value of the dot11CountryString to the value contained in this field.” • Applies to WAVE

  40. Regulatory Class in 802.11 • Regulatory classes are defined in Annex J • Regulatory class indexes are distributed in the Country info element • E.g., in the Beacon frame • “allow a STA to identify the regulatory domain in which the STA is located….” • “allows a STA to configure its PHY and MAC for operation….” • Regulatory classes are stored in the MIB • Processing of received Regulatory Class is not explicitly specified, even for non-WAVE devices

  41. Coverage Class element • 802.11 • 7.3.2.9: “describes variations in actual propagation time that are accounted for in a BSS and, together with maximum transmit power level, allow control of BSS diameter.” • 10.4.3.2 “Twice the propagation time (in microseconds) for a signal to cross the maximum distance between the most distant allowable STAs that are slot synchronized.” • 17.3.8.6 “slot time shall be increased by the value of 3 µs × coverage class.” • 802.11y/9.8.4 provides more description • In BSS context • WAVE • Seems like we need this on each channel • 802.11 increases slot time for >1 µsec propagation time end to end round trip (coverage radius >~250 feet) • FCC defines zones for Classes C/D at 400m and 1000m

  42. Example coverage geometry and timing aAirPropagationTime = 1µs r ~250 ft Larger coverage zone should use larger aAirPropagationTime and longerslot time

  43. Power Constraint in 802.11 • 7.3.2.15 “… contains the information necessary to allow a STA to determine the local maximum transmit power in the current channel.” • When it’s sent • 802.11: Mandatory in Beacon & Probe Response IF dot11SpectrumManagementRequired is TRUE • 802.11p: Optional in Timing Advertisement IF Country is present • Not clear what constitutes “local” in WAVE • Use on reception • 11.8.2 “A STA shall determine a local maximum transmit power for the current channel. The STA shall use the minimum of the following: • — Any local maximum transmit power received in the combination of a Country element and a Power Constraint element from the AP in its BSS or another STA in its IBSS and • — Any local maximum transmit power for the channel regulatory domain known by the STA from other sources.”

  44. Power Constraint or Transmit Power Level? • 802.11 uses Power Constraint to indicate the difference between max allowed regulatory power, and the “local” power profile on the current channel • 1609 uses Transmit Power Level to indicate the maximum allowed power on a specific SCH, announced in the WSA • Should 1609 adopt Power Constraint for consistency? • I recommend NO, because • The field is not well defined in 7.3.2.15: • “The Local Power Constraint field shall be set to a value that allows the mitigation requirements to be satisfied in the current channel. The field is coded as an unsigned integer in units of decibels relative to 1mW. The local maximum transmit power for a channel is thus defined as the maximum transmit power level specified for the channel in the Country element minusthe local power constraint specified for the channel (from the MIB) in the Power Constraint element.” • Should be in units of decibels • There is no Power Constraint element in the MIB • The field is defined relative to “the current channel,” which is not adequate for WAVE

  45. Transmit power in 1609 • 1609 sets transmit power in two cases: WSM and Tx Profiles • WSM • Higher layer originating entity requests tx power for message • Power setting passed down the stack to the PHY • Tx Profile • Higher layer Provider sets Transmit Power Level for SCH • Announced in Channel Info of WSA • Provider and User WME “register” tx profile with 1609.4 MLME • MAC layer uses registered tx power to set transmit parameters in TXVECTOR to PHY • The 1609 stack could, but does not, verify regulatory limits are not exceeded

  46. TxPwr_Level is registered with the Provider MLME for SCH transmissions Provider WME could verify power constraints not exceeded Transmit Power Level advertised in the Channel Info of WSA Transmit Power Level converted to TxPwr_Level at User for SCH transmissions User WME could verify power constraints not exceeded Additionally, the transmit power level of the WSA itself may be passed to the User Tx Power for IP on the SCH

  47. Tx Power for WSMs on the SCH or CCH • Higher layer sender requests Transmit Power Level for WSM • Absolute Transmit Power Level converted to TxPwr_Level index and sent through WSMP, LLC, and MAC to PHY • Sender WME could verify power constraints not exceeded • Additionally, the transmit power level of the WSM may be passed to the recipient via the WSMP header

  48. Transmit power level in the MIB • 1609.3 • Channel Info • Transmit Power Level • Set via configuration for IP traffic, per SCH • Available Service Info • Transmit Power Level • From received WSA, for IP traffic, per SCH • 1609.4 • Transmitter Profile • PowerLevel for IP traffic, per SCH • Received from WME • 802.11 • PhyTxPowerTable • TxPowerLevel 1-8 • CurrentTxPowerLevel • MultiDomainCapabilityTable, list of • MaximumTransmitPowerLevel, per channel set

  49. What the FCC says about DSRC regulatory issues • I don’t find anything in relevant sections of CFR 47 Parts 90 & 95 that guides us on dissemination of channel or power info over the air

  50. Possible strategies • 802.11 directs how general stations perform regulatory power control based on received information • But no guidance on how this is done in WAVE • Options: • Solve it in 802.11p • Doubtful • Manage the process in 1609.x • And hope we get everything right first time! • Provide hooks in 1609 and assume an operational solution

More Related