comments by cuiliqing

VIEWS: 5 PAGES: 22

									    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 7.2.1.1.   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 7.2.1.2.   T The Local Service index should be returned on an
Alastair                          2     "Add" action
Malarky,   Malarky/22   8.1.2.3    T Treat WRA like other optional elements and use
Alastair                             header bit to indicate presence
Malarky,   Malarky/23   8.1.2.8    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   8.1.2.8    T How and by whom will header extension element IDs
Alastair                             be managed ?
Malarky,   Malarky/25   8.1.2.8    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   8.1.2.8    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   8.1.3.2.   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   8.1.3.2.   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        6.2.1.2       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   6.2.1.3   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    6.2.2.1   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    6.2.2.3   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    6.2.3.2   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   6.2.2.2   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       7.2.1.1.       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       7.2.3.1.       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 7.2.5.1 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.

								
To top