VIEWS: 5 PAGES: 22 POSTED ON: 8/7/2011
Name Comment Page Sub- Lin Typ Comment Number clause e e of Malarky, Malarky/10 17 6.5 Nu Com This and later Table 1 just points to 802.11k. T Alastair Because of security issues we may not be able to use the 802.11k action frames. This discrepancy needs addressed. Malarky, Malarky/6 17 6.5 T The RCPI capability needs to support both WSM & Alastair IP higher layers. Malarky, Malarky/9 17 6.5 T One of the options that needs to be considered this Alastair that the MAC address is set to the same for multiple WAVE only devices. If true the Peer MAC address will not be meaningful in all cases to select a single device. Malarky, Malarky/11 18 7 Fig T There should be a SEC SAP to higher layers shown Alastair 10 in diagram and entries in table for app access to & security. Tab le 1 Malarky, Malarky/15 8.1 T If we are going to have flexible channel interval, or Alastair variable CCH/SCH division, there needs to be a specific element in the WSA for this. Malarky, Malarky/16 8.1 T The new WSA has location information as optional Alastair information. Where is this obtained from ? SAP, MIB variable ? Malarky, Malarky/17 8.1 T The use of EUI-48 address, declaration of 1609 IAB Alastair for 1609 and overlap with VSIE OUI, and fragmentation of WSA should be addressed here and not in 1609.4. The 802.11p Timing Advertisement fields should be identified along with their relevance to 1609. (e.g. Power Contraint only applies to channel the frame is received on). Note EUI-48 is outside signature. Malarky, Malarky/18 8.1 T Suggest that last 12 bits of EIU-48 should be 1 octet Alastair for WAVE version, and 4 bits to identify content of 1609 VSIE : ( e.g. unsigned WSA, signed WSA, unsigned no WSA frame, signed no WSA frame, Action field (see 6.5)) Malarky, Malarky/12 19 7.1.1 T The higher layer may set parameters to invalid Alastair values ( eg TX power exceeds local/current regulations, invalid security type). Some means of flagging the layer that the parameters are in error is required. This may also apply to other primitives. Malarky, Malarky/13 21 220.127.116.11. T The Local Service Index should be assigned by the Alastair 2 WME on a "Add" action. Don't think it should be a IP and port equivalent. This doesn't mean anything if it is WSM. Malarky, Malarky/14 22 18.104.22.168. T The Local Service index should be returned on an Alastair 2 "Add" action Malarky, Malarky/22 22.214.171.124 T Treat WRA like other optional elements and use Alastair header bit to indicate presence Malarky, Malarky/23 126.96.36.199 T After all the arguments on the length of PSID and Alastair PSC, why are we allowing header extensions of 255 bytes ? Malarky, Malarky/24 188.8.131.52 T How and by whom will header extension element IDs Alastair be managed ? Malarky, Malarky/25 184.108.40.206 T I presume one reason for the header extension is to Alastair allow addition of new header elements without changing WAVE version since ignoring new header elements will not compromise older version WAVE units. Malarky, Malarky/26 220.127.116.11 T I presume one reason for the header extension is to Alastair allow vendor specific addition of new header elements. I don't think we should do that in the WSA. Malarky, Malarky/31 18.104.22.168. T Why do we need to use up an octet per channel for a Alastair 4 bipolar value. Use one of the channel content bits. Malarky, Malarky/32 22.214.171.124. T 802.11 defines a variable number (default 8) Alastair 6 dot11TXPowerLevel MIB entries, however the meaning of this MIB variable is up to the implementer. However since we are using this to transfer information between STAs, 1609 must define the units and coding for the WSA. ---- 802.11 doesn't because it covers all the 802.11 modulations etc and bands where regulations are specified differently. We need to know exactly what it means for 1609 since we are transmitting from one STA to another. Also the data needs to be available to entity that requests TX power setting for channel. Malarky, Malarky/48 41 8.2.10 T What is the need for an extended header field ? The Alastair WSM version would encompass header extension common to all WSM. Who manages element ID ? Why isn't this element at end after message data, rather than in middle of packet ? The max length of 255 is excessive for a header extension. Multiple header extensions seems also excessive for a data packet. Malarky, Malarky/38 40 8.2.4 T Because the security is set by the higher layer, it Alastair should be made clear that the security mechanisms for the identified types are those from 1609.2 applied using security SAP (see previous comment re Figure 10 and Table 1) Malarky, Malarky/39 40 8.2.4 T Recommend adding 2 extra entries "non-1609 PSID Alastair specific signature" and "non-1609 PSID specific encryption". Since higher layer is responsible for security, it is not constrained to use 1609.2 in all cases. Malarky, Malarky/40 40 8.2.4 T It has been discussed that 1609.2 may expand to Alastair support a range of security levels. This may result in additional entries. 1609.1 may also use a different level of security. Malarky, Malarky/41 8.2.5 T Why does the channel number used to transmit Alastair need to be in the WSM. The receiver knows what channel the WSM is received on. Malarky, Malarky/45 8.2.7 T 802.11 defines a variable number (default 8) Alastair dot11TXPowerLevel MIB entries, however the meaning of this MIB variable is up to the implementer. However since we are using this to transfer information between STAs, 1609 must define the units and coding for the WSA. Malarky, Malarky/51 Genera T There needs to be a means for the higher layer to Alastair l obtain the IP and port address currently assigned to it and to receive notifications if this is changed (e.g. by MAC address change for security reasons). Malarky, Malarky/53 Genera T The fact 802.11 lists channel numbers that are not Alastair l supported by current regulation should be addressed/stated. 1609 should be limited to regulated channels applicable for the regulatory domain it is used in. Malarky, Malarky/54 Genera T I believe there is a need for a STA to be able to Alastair l request other STAs to transmit the timing information so that it can obtain time. Currently there is no way other than waiting for a provider to come into range. Malarky, Malarky/55 Genera T At last meeting there was discussion and action Alastair l assigned to address need for performance data. Nothing is defined in current versions Proposed Change Discussion May need to have WAVE action frame which The issue is how do we protect mimics 802.11k frame but with security and which from denial attacks. Wihout results in 802.11k capabilities being accessible. some form of authentication of This could be carried as a Timing Advertisement the request STAs can be frame but with Action field instead of WSA. swamped by false requests. Even i if they limit the number they will respond to, unathenticated requests will interfere with legitimate usage. I think we may be able to resolve this - it appears that we need to use a VSIE in the 802.11 Action Frame. This VSIE can contain a 1609 authentication of the request. Make this a general service accessible from IP Will consider adding the based services also. E.g. require Peer MAC capability to query RCPI by IP address be set to lower x octets of IPv6 address of address. targetted unit (assumes IPv6 address is constructed using MAC address) Agree. Add a SAP No. Here we only address SAPs directly relevant to this document. What you suggest should be in 1609.2 & 1609.0. Will define optional field(s) indicating interval size. Will consider adding optional MIB attribute of location. This is part of the overall resolution to 802.11p. The reason I say it should be in 1609.3, is because that defines the entire WSA and it's usage - the only field that 1609.4 addresses is the use of the timing information field. Fragmentation etc is not a function of channel timing or synchronization but purely a function of the 802.11 frame used. The encapsulation of the WSA into the 802.11p frame should be in 1609.3, depending on the final form of 11p.. For group discussion. Will have to wait for a stable 802.11p before evaluating this. OK. Note that SAPs are implementaiton dependent. Add clarifying text. OK Add parameter See #21 Probably a good idea. If we keep them, limit extensions to 8 octets. Solicit guidance from the group as to max size of header extension fields. Good question. I suggest a registry in the 1609 group. Delete header extensions and add 1 octet to WSA Suggest using vender data which is "backward compatibility version number". elements in 802.11p frame. This covers any future header or WSA changes while controlling backward compatibility. The higher layer headers should not be part of the 1609 fields. The 802.1 frame allows addition of any number of See #25. vendor specific information elements. Any vendor extensions of 1609 can be handled using this without introducing WSA complications. Will consider if this can be done while maintaining consistency with the intent of "Content" fields. define TXPwr_level coding and meaning The logic does not necessarily hold; the number could be valuable as a relative value. I hate to impose power measurements requirments in 1609, especially if 802.11 did not feel able to. Prefer no change but suggestions welcome. There is no processing specified on receipt of the value. (In fact it is passed mainly for the same reason as channel number, see #41.) Delete this and add in a new element which is The intent is to allow extensions "backward compatibility version number". This defined outside the 1609 main solves the same problem while allowing the new track, e.g., by apps or by ISO. header elements to be documented in the Say an app want to mark a msg standard. for relay via a header extension. A base 1609 receiving unit could ignore the relay filed but otherwise process the message. AN ISO relay unit could read the extended header and act on it. See #25. add clarifying text OK add recommended additions OK OK Delete channel number The tx channel number is passed from layer 3 through LLC to the MAC in the WSMP header, with the awkward consequence of the channel no set over the air. Otherwise the MAC would have to modify higher layer information. See Fig 15 and 1609.4/Fig 4. define TXPwr_level coding and meaning Repeat of #32 We should have notification(s) generated by the dot4 anonymity process when thye address is changed. In general, IP address is accessible via normal mechanisms, e.g., IP MIB. Alastair to offer suggested text. Add a means to request this Alastair to offer suggested text. This is for group discussion+I32 For group discussion. First identify performance metrics, then where to specify them: dot0? PICS? Name Comment Page Sub- Line Typ Comment Proposed Change Number clause Nu e of Moring, John moring4 5.1 mbe Com Here we specify no transmissions during the T guard interval. Should this apply if the tranmitter is not switching channels? Also affects clause 6. Moring, John moring5 general T The identification of mandatory requirements vs optional features needs to be reviewed for clarity, consistency and correctness. Moring, John moring6 6.2.3 T It might be desirable to process partial, meaningful, WSAs. Consider alternate segmentation approaches to maximize the chance of receiving suable data when a segment is lost. Moring, John moring8 6.3.2 T "…shall be reset to a new random value each time before a service channel access is initiated" does not cover the case of a non-switching device. Moring, John moring9 Annex D T There seems to be multiple EDCA tables in 1609 and 802.11. Review to insure there is no conflict. Moring, John moring11 5.1 T Table 1 misrepresents the types of WSMs allowed on CCH during CCH interval. Any WSM is allowed on any channel at any time, but priority 4+ MUST be sent AT LEAST on the CCH in the CCH interval. Moring, John moring12 general T Will need update to reflect any changes in 802.11p. Weinfield, Aaron Weinfield1 24 6.3.1 T Anonymity on the CCH does not appear to be If anonymity is not required for an OBE supported for the provider role. A unique and acting as a provider, add the following valid source MAC address is needed when statement to Section 6.3.1: "Devices processing received WSA indications (e.g., when acting as a provider shall not use an combining HLIE segments and when obtaining anonymous or changing MAC address the BSSID for the SCH). on the CCH". If anonymity for a provider is required, specification must be revised to support provider anonymity. Li, Michael li1 126.96.36.199 T Should there be a way to communicate with other devices when switching to immediate SCH access or indefinite SCH access? Otherwise the other devices may not know to switch accordingly. Fuereder, Herbert 25 6_3_3 T I think there is quite a chance that two devices which are in a tuning range choose the same MAC-address? Fuereder, Herbert 27 7_2_1_ T There is no possibility to have a WSA sent every 1_2 2nd or third CCH intervall. Could not that be needed also? I thinik a Beacon every 100 msec is quite often, even if a car goes with 150 km/h. Malarky, Alastair Malarky/1 5.1 T There may be a need to specify here that devices that are not operating in time sync, are only not permitted to transmit on channels adjacent to the control channel. This prevents unwanted interference to the CCH in the CCH interval. Transmission on non-adjacent SCHs may be needed for 1609.1 and should have no impact on CCH operation. Malarky, Alastair Malarky/2 Table 1 T There should be no reason to prevent the Separate timing frame only from WSA transmission of a timing advertisment frame transmission (without WSA) on the SCH channel. ---- I think there is a need to have this. This all comes about whether we can transmit Timing Advertisement without WSA in 1609. Should be discussed at group level Malarky, Alastair Malarky/3 5.3 T 802.11p defines separate EDCA for change to use default EDCA parameter OCBEnabled. It will be a different table from 7- settings for OCBEnabled in 802.11 37. Malarky, Alastair Malarky/4 188.8.131.52 T Indefinite access has potential implications for A better method might be a fixed time other services. An application can lock the access to channel with option to renew device to a service channel. where other services have chance to ------------- contend. If one app requests indefinite SCH access and decides not to release, no equal level app will ever be able to get access to WSAs and other service channels while that app has service coverage. Malarky, Alastair Malarky/5 6.2.2 T The segmentation of the WSA and the 802.11 frame belongs in IEEE 1609.3. Only the use of the timing information element belongs in 1609.4 as well as the timing of WSAs. ----- I don’t necessarily agree. Since 1609.2 adds security after 1609.4 elements are added, and 1609.3 will add VSIE elements in front of this, 1609.4 does not know the final size. By your argument since the signing is invoked by 1609.3 and VSIE prefix is added at 1609.3, therefore it belongs in 1609.3. Malarky, Alastair Malarky/6 184.108.40.206 T Because we can transmit multiple VSIEs in one Timing Advertisement frame, the segmentation will not result in separate MLME- TIMING_INFO.requests. Malarky, Alastair Malarky/8 220.127.116.11 T Because we can transmit multiple VSIEs in one Timing Advertisement frame, the segmentation will not result in separate MLME- TIMING_INFO.requests. Malarky, Alastair Malarky/9 18.104.22.168 T Because we can transmit multiple VSIEs in one Timing Advertisement frame, the segmentation will not result in separate MLME- TIMING_INFO.indications for one frame. Malarky, Alastair Malarky/10 6.2.x T There is a need for requesting transmission of Timing Advertisement frames without WSAs and with or/without authentication, on a regular basis. These may be on service channel too Malarky, Alastair Malarky/11 6.2.x T Ability to support timing information frames without WSA (but with signature protection in VSIE) should be addressed Malarky, Alastair Malarky/12 22.214.171.124 T The timing information being added in 802.11p if different to the one described here. In particualr there is no GPS indication in the 802.11 version. Malarky, Alastair Malarky/13 6.2.3 T Figure 17 indicates timing information is stripped Provide capability by MLME. However the higher layers may also need access to UTC created by this. Where is this capability defined ? Malarky, Alastair Malarky/14 7.1 T Need primitive to access UTC by higher layers Malarky, Alastair Malarky/15 7.1 T If UTC timing estimation and monitoring against external clock is managed external to the WME then primitives needed for such service to update WME and set timing information fields. Malarky, Alastair Malarky/16 7.1 T Need primitive to create Timing Advertisement frames identified as 1609 and with/without signature. Malarky, Alastair Malarky/17 7.1 T Need primitive to create Timing Advertisement frames identified as 1609 and with/without signature and on specifc channel(s) Malarky, Alastair Malarky/18 7.1 T Need primitive to identify receipt of Timing Advertisement frames identified as 1609 and with/without signature. Malarky, Alastair Malarky/19 126.96.36.199. T See no valid reason to permit WSA to go to Delete Peer MAC address from WSA 2 individual destination. request Malarky, Alastair Malarky/21 188.8.131.52. T TxPwr_Level should refer to 1609.3 or be 2 renamed to TransmitPowerLevel. 802.11p does not define TxPwr_Level. Proposed to consider that the MAC and PHY services may not be 802.11 This assumes that underlying services based. Perhaps consider a language F. Simon 9 4.2.1 5 General - 8 T (MAC/PHY) are 802.11 MAC and PHY. which is not 802.11 specific. This bullet assumes underlying 802.11 MAC/PHY. See comment # 9. In addition, the Timing and Information frame in P802.11p has Propose to consider the comment. been replaced by "Timing Advertisement " Perhaps a language which is not F. Simon 10 4.2.2 General 5 13 T management frame. 802.11 specific. Discussion For further study To be incorporated in next draft. For further study We've incorporated the VII anonymity scheme with only eidtorial changes. Request comments whether this is adequate, and if not, what is needed. See Weinfield1. For further study To be corrected next draft We've incorporated the VII anonymity scheme with only editorial changes. Request comments whether this is adequate, and if not, what is needed. See Moring 8. We considered this, but did not come up with a scheme that seemed both simple and effective in all scenarios. Since different higher layers have different needs, we chose the same approach as for general SCH access, i.e., this is not done in the stack, but can be done by the higher layer, e.g., using PSC or WSM. I calculate 60+ trillion possible addresses, making the chance of duplicates within a short-range coverage area small. A requirement for this feature has never been identified. Because people have relaxed specs even further on adjacent channel interference in 802.11, transmission by STAs during the CCH interval on the adjacent SCH can reduce the interference free range of the CCH. 1609 defines no use of TAF on SCH, thus the requirement. If there are uses, we can relax this. OK We do allow higher priority apps to request normal CCH access, precluding lower priority indefinite SCH access. I think this provides a good balance between simplicity, functionality, and app priority. 1609.4 adds content to the frame, so it knows the final size. It also processes info in the frame. I think segmentation is appropriate where it is at present. Final solution dependent on 11p update. The doc is written against 11p D5.0 and will have to be updated when the 11p stabilizes. See #6 See #6 For group discussion. See #10 See #6 Dot4 offers 184.108.40.206 MLME- GETUTCTIME.request. If this needs to be visible to higher layers above WME, it could be made so in implementation, or via the dot3 in the WME SAP. (Note lower layer MIBs are accessible to higher layers through their own SAPs.) See #13 See #13 See #10 See #10 See #10 Agreed in the Trial Use std, in case a Provider wants to invite a specific User. 802.11 uses TxPwr_Level. Will have to check references allign parameter usage. I've always understood that the lower layers of WAVE are 802.11. 802.11p has changed since this document was publish. Will sync when 11p stabalizes.
Pages to are hidden for
"comments"Please download to view full document