Dot3 and dot4 issues

1. Dot3 and dot4 issues John Kenney Feb. 2010

2. UDP/TCP • Should we recommend UDP? • No. Choice of transport protocol is application dependent. • Affects 5.1 and 5.4&5.5 • Dot3/5.1: “UDP recommended as the primary transport protocol because of its low overhead and latency”

3. UP4 and higher/ CCH Interval • 1609.4/Clause 5.2.3 “WSMs with user priority 4 and higher shall be sent at least on the CCH during the CCH interval.” • Also: "User priority 4 and higher shall be transmitted on the CCH in the CCH interval, and may be transmitted on other channels in any interval." • Unclear (what exactly does it mean?) • Ill-advised. User priority only has meaning within a channel. There are UP4+ frames that should only be sent on a SCH, where that priority is relative to priority of other frames on that channel. • Within the CCH, this may be outdated. Ex: under (Intention, CCH) approach, safety messages might be sent on CCH during SCH interval. • Under current 802.11, management frames must be mapped to UP7

4. Use of Default EDCA • Dot4/5.4.2: “The default EDCA parameter set specified in IEEE P802.11p for OCBEnabled operation shall be used when operating on the CCH.” • What confidence do we have that these are values are appropriate? • BSMs will dominate CCH under certain safety models. Should probably be mapped to AC0. • Management frames mapped to UP7AC3. Do AC3 parameters hurt safety?

5. Guard Interval parameter values • SyncTolerance and MaxChSwitchTime • Where do the values come from? • Dot4(d3.0)/5.2.2: “The duration of the CCH and SCH intervals are set by policy and stored in the MIB CchInterval and SchInterval respectively…” • Local policy or global policy? • How is interoperability achieved if they are determined locally? • Default values? In MIB? In dot4?

6. Reserved bits • Propose to reduce WSMP Version to 4 bits and reserve the other 4 bits • Propose to reduce WSM Length to 12 bits and reserve the other 4 bits • Suggest this be reflected in Fig. 22 or equivalent diagram.

7. What is delivered above WSMP-S? • Annex G appears to have conflicting information about what WSMP-S delivers to higher layer. Is WSMP-S Control Field included? • Dot3 (d3.0)/G.2.1: “this registration causes the WSM Data to be delivered to the higher layer regardless of whether the Data also includes the WSMP-S Control field” • Dot3 (d3.0)/G3.4 indication primitive parameters includes Payload, not WSM Data. • Suggest WSMP-S parse WSM Data into two pieces: Control Field and Payload and pass these up as separate primitive parameters

8. WSM definition • Dot3/5.6.2: “WSMP shall generate the WSMP header per 8.3 and pass the short message data and header to the LLC” • I suggested “and pass the WSM to the LLC” • Response is that WG has not decided what a WSM is. • We should have a clear definition of a WSM • Propose adding “WSM: a packet consisting of WSM data and a WSMP header” to definitions in clause 3. Then refer just to WSM above (I have a specific suggested revision of this sentence)

9. WAVE Element ID – 2 uses • We use the term WAVE Element ID in two distinct ways. • Annex F includes WAVE Element ID values associated with WSAs, WSM extensions, and WSM data • 8.3 uses WAVE Element ID to name the field that precedes WSM Length. • Lots of fields take WAVE Element ID values • Propose that WAVE Element ID refer to values (as in Annex F). Propose WSM header field be called “WSM Type”

10. Delivery to multiple higher layer entities • Dot3/5.6.1: “While acceptance of a received frame at the MAC layer is determined by the destination address, delivery of a received WAVE short message to a higher layer entity is determined by PSID. Thus a given received message may be delivered to multiple higher layer entities at the destination, and a broadcast message will be accepted by only that subset of receiving devices with interest in the associated PSID” (emphasis added) • Is acceptance in a device a function of the MAC address or the PSID? • If multiple higher layer entities in a device are to receive components of a given WSMP, what is the interface to them? Does WSMP use a single indication primitive, which somehow is effectively broadcast to all these higher layers? Or, does WSMP use a separate indication primitive per higher layer?

11. DL-DATAUNITX.confirm? • We have DL-DATAUNITX.request primitive. • We have one identified failure condition (length exceeds maximum) • We should have a DL-DATAUNITX.confirm to convey the success or failure of the request

12. Power request not possible • Dot3/5.6.2: “TxPwr_Level is set to the index of the highest value of IEEE 802.11 MIB Dot11PhyTxPowerEntry that does not exceed Transmit Power Level” • If Transmit Power Level is less than all MIB entries, do we want to leave it up to an implementation to decide what to do? Affects over-the-air. • Propose that if the requested power cannot be accommodated the request should fail.

13. Channel Number description • Dot3/8.3.4.2: “Channel Number is optionally included in the WSMP header for use by the WSM recipient.” • Propose adding "Channel Number is specified in IEEE Std. 802.11"

14. WSM parsing rules • Dot3(d3.0)/8.3.1: “the beginning of the WSM Data is preceded by a WAVEElement ID value indicating WAVE Short Message or a WSMP extension (see Annex F) and WSMLength” • I think reference to WSMP extension is incorrect. If Element ID value indicates an extension, then the WSM Data does not follow • Need terminology to indicate any of the set of Element IDs that indicate the start of the WSM Data field.

15. MLME vs MLMEX in dot4 • Primitive definitions and consistency with 802.11 • Dot4 6.4.1.1 and Fig. 14. What is the 1609.4 MLME? Does it make sense for the MLME to send itself primitives?