Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This...

12
March 1995 Simon Black Syrnbionics Ltd Cowley Rd. Cambridge CB4 4WS UK Phone: +44 1223 421025 Fax: +44 1223 421031 E-Mail: [email protected] IEEE P802.11 Wireless Access Method and Physical Layer Specification Section 4 Response to Draft Dl Letter Ballot Processed at March 1995 Meeting Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC group that is resolving the comments on section 4 of 802. 1 lID 1. The comment numbers in the TAG column cross reference to the numbers in the technciaVeditorial column in document P802.11-95/65. Responses in bold are not definative because either the issue is too large for a small working group, or because we need input from a group that is working on another section. The comments reviewed are largely those that the author marked as technical, though here we noted an editorial comment that addressed the same issue we bundled that in as well. These are marked with an (E) following the authors name in the table below. Action: Adopt the changes in PS02.11-95/66 to replace the relevent portions of Section 4 ofPS02.11/D1, as shown in the companion document PS02.11-95/5S. Submission Page I of 12 Simon Black, et. al.

Transcript of Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This...

Page 1: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995

Simon Black Syrnbionics Ltd Cowley Rd. Cambridge CB4 4WS UK Phone: +44 1223 421025 Fax: +44 1223 421031 E-Mail: [email protected]

IEEE P802.11

Wireless Access Method and Physical Layer Specification

Section 4 Response to Draft Dl Letter Ballot

Processed at March 1995 Meeting

Doc: IEEE P802.l1-95/66

Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC group that is resolving the comments on section 4 of 802. 1 lID 1. The comment numbers in the TAG column cross reference to the numbers in the technciaVeditorial column in document P802.11-95/65. Responses in bold are not definative because either the issue is too large for a small working group, or because we need input from a group that is working on another section. The comments reviewed are largely those that the author marked as technical, though here we noted an editorial comment that addressed the same issue we bundled that in as well. These are marked with an (E) following the authors name in the table below.

Action: Adopt the changes in PS02.11-95/66 to replace the relevent portions of Section 4 ofPS02.11/D1, as shown in the companion document PS02.11-95/5S.

Submission Page I of 12 Simon Black, et. al.

Page 2: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag I Section I Author I Proposal I Recommendation

'Lag Section Author Proposal Recommendation

1 4.1 Chris Zeglin BitIByte ordering make clear - 1.6 does not contain octet ordering - eg for TomT duration field. J Renfro A Bolea

2 4.1.1 J Rosdahl Frame format should be: Recommend yes A Bolea Frame control 2 octets B Dobyns DuarationlConnlD 2 octets C Heide Address 1 6 octets T Baumgartner Address 2 6 octets M Fischer Address 3 6 octets S Black (E) Sequence control 2 octets M Okada (E) Address 4 0/6 octets Rackowitz (E) Frame body 0-2304 TomT CRC 4 octets R White (TIE) B O'Hara (E) E Geiger (E) S Vesuna J Renfro (E) G Sherwood J Kubler Fischerma D Bagby

3 4.1.1 A Bolea Move Duration field Recommend no, duration field must stay in fixed position J Renfro (to allow easy hardware implementations). Only other

possible place is after address 1, but this is messy since it ends up between address 1 and address 2.

4 4.1.1 M Fischer 2304 -2312 octets with ICv/IV - where does 2304 come 2304 = 2048 (application data size) + 125 (worst case from protocol overhead) + 5 (802.2 SNAP header) + 30 (source

routing).

Optional field in data frames for IV (16 bits before MSDU) and ICV (32 bits after MSDU).

5 4.1.1 M Demange Protoected MAC header to shorten turnaround - big change Recommend no, big change with little support in the working group.

6 4.1.1 T Phipps Delete section. Recommend no, generally felt diagram useful - comment editorial, perhaps make diagram clearer to show fileds that I are not in all frame _types (grey?)

Submission Page 2 of 12 Simon Black, et. aI .

Page 3: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 [Tag ! Section ! Author I Proposal I Recommendation - - ----- - - )

7 4.1.2.1 Jim Panian Generally felt useful. Note M fischers comment on WEP bit Recommend yes in comment 12 and paper 95/06. Compression not in standard so no need for compressed bit, but note no reserved bits left.

a 4.1.2.1 C Heide Clarification of which frames field in frame control field are Editorial valid

9 4.1.2.1 Joe Kubler More bit in frame control field removed to power Recommend no management field (sections 7.2.1.6, 7.2.1.7 inconsistent)

10 4.1.2.1 McDonald More bits for version number. Recommend no, larger control field, protocol extensions J Panian (E) fundamentally incompatible at frame level will be rare.

11 4.1.2.1 Wim Dieptraten Agree with intent - that is to specify how to set FC bits in Recommend no, but note to check definition of when bits various frame types, disagree with two of Wims comments used and what values they take in each section. - Power management (should be allowed in all)and EP (elements in management only).

12 4.1.2.1 M Fischer Rsvd bit in frame control field becomes 'frame body Recommend yes, but note no reserved space in frame encrypted bit' control

13 4.1.2.1.1 Rick White Define initial protocol version as 00 Recommend yes 14 4.1.2.1.1 M Fischer ... without indication to LLC Recommend yes 15 4.1.2.1.1 S Vesuna Shall discard frame with higher protocol version becomes Recommend no, since discard only way to ensure defined

may discard behaviour 16 4.1.2.1.2 B Dobyns Complete rtM)rganisation of types Flag

A Bolea Remove (no data) data frames since Data can have o Bagby length -O?

Move Null to control 17 4.1.2.1.2 C Heide Drop asynch from asynch data Recommend yes

T Baumgartner 18 4.1.2.1.2 M Demange Merge association and reassociation - suggestion is Flag, but note that may be better to keep seperate from

that practically these could be the same. Re- standards view point - to keep the two things logically association is practically deassoclate plus associate. seperate.

19 4.1.2.1.2 T Phipps Add CF END + ACK since no way to ACK last CF-DOWN Recommend no, user CF-ACK (zero data) then CF-END (would usually be in CF-UP)

20 4.1.2.1.2 Wim Diepstraten Suggestion that CF-TBS added. Recommend no, since if CF then ConnlD instead of duration

21 4.1.2.1.2 M Fischer Have PS-Poll replace Poll to avoid confusion with CF-Poll Recommend yes 22 4.1.2.1.2 P Prenner Merge certain high level management frames, create Flag, but could split into lower and upper management

more reserved. Some are time critical - probe-probe functions - use the 00 type for one and the reserved 11 response, some are higher level functions. type for the other. Alternatively for non-time critical

could use an element for sub-type.

Submission Page 3 of 12 Simon Black, et. a1.

Page 4: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag ! SeCtion I Author I Proposal I Recommendation

23 4.1.2.1.3 B Dobyns Problem with toOS - can generate out-of-sequence Flag, can't stop re-ordering ? LLC should fix in an ideal o BaQbv packets world.

24 4.1.2.1.3 C Heide STA uses ToOS field whenever going via an AP - OS Recommend that when associated the ToDS bit should T Baumgartner Services include relaying within a BSS default to true. Default does not mean must M DemanQe

25 4.1.2.1.3 RWhite Any frame to another ST A must have OS bit set Recommend no 26 4.1.2.1.4 RWhite This one bit field shall indicate that the frame is being Recommend yes

distributed from the distribution system iR aR iRfi:astFl:lstl:lFe RetY.f6I'k.

27 4.1.2.1.4 M Fischer Add text to To/FromDS both 0: A frame direct from one Recommend yes station to another station in the same BSS

28 4.1.2.1.5 Tom Only data frames fragmented Recommend no Baumgartner

29 4.1.2.1.5 M Demange Define sense of Last Fragment Bit (1 is last frag, 0 is more Recommend yes A Bolea (E/T) following) RWhite S Vesuna

30 4.1.2.1.6 J Kubler Retry bit Recommend yes A station ffiaY-shall use this indication to aid in the process of eliminating duplicate frames

31 4.1.2.1.6 M Demange Define sense of Retry Bit (1 is retry, 0 is first transmission) Recommend yes RWhite

32 4.1.2.1.7 B O'Hara Power management bits. Recommend yes R White (E) 'These bits shall remain constant for each frame sequence M Demange (E) described in section 4.3' J Rackowitz (E) A Bolea (E) S Vesuna (E) E Geiger (E) G Sherwood (E)

33 4.1.2.1.8 C Heide Reword 'elements present': Recommend Jon Rosdahl's reworded J Rosdahl This one bit field shall be set to one if there are one or more

elements present in the frame body. This field shall be used for management type frames only. This field is reserved for all other frame types and shall be set to 0_. _ _ _

Submission Page 4 of 12 Simon Black, et. aJ.

Page 5: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 [rag I Section I Author I Proposal I Recommendation- - -- - - J

34 4.1.2.1.8 C Heide Remove EP bit as redundant since elements only ever Recommend yes T Baumgartner present in management frames A Bolea B O'Hara D Bagby

35 4.1.2.2 B O'Hara Change duration time to bit times and no Flag M Fischer microseconds. Also referece to calculation in section I

J McDonald 5. RWhite Miceli o Bagby

36 4.1.2.2 C Heide Last sentance; remove parenthesis and reword: Recommend yes T Baumgartner I

M Fischer Only contention Free Time Bound service frames use a S Vesuna (E) connection 10; asynchronous data frame do not use A Bolea (E) connection 10

37 4.1.2.2 J Kubler Always use ConnlD rather than Duration in CF. ConnlD Answered comment only used for TBS therefore use reserved value of ConnlD (all O's) for sync data.

Add to above sentance: This field Is reserved for CF Asynchronous ~ata Frames and shall be set to O.

38 4.1.2.2 W Diepstraten ConnlD necessary for time bounded - exists at the MAC Perhaps need to carity use of ConnlD service boundary to identify connection.

39 4.1.2.3.2 M Fischer Delete final sentance of 4.1.2.3.2 Recommend no (leave) E Geiger It is not necessary that a station be capable of generating

the broadcast address 40 4.1.2.3.3 E Geiger Measures shall be taken In the selection of the value of Flag - how do you choose initial BSSIO in Ad-hoc

GSherwood this field to differentiate it from other ad hoc networks network. Choose MAC address of initiating station. T Phipps In the vicinity. Much discussion I

41 4.1.2.3.3 RWhite BSSID clarifiaction - address of STA in AP Recommend yes 42 4.1.2.3.4 M Fischer Improved wording of destination address definition Recommend yes

C Heide 43 4.1.2.3.5 M Fischer Improved wording of Source address definition Recommend yes

--

Submission Page 5 of 12 Simon Black, et. aI.

Page 6: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag I Section I Author I Proposal I Recommendation ---]

44 4.1.2.3.6 M Fischer Improved wording of receiver address definition Recommend yes RWhite C Heide J Rosdahl

45 4.1.2.3.7 C Heide Allow broadcast TAIRA Recommend no, not logical. P Brenner

46 4.1.2.3.7 M Fischer Improved wording of transmitter address definition Recommend yes J Rosdahl RWhite

47 4.1.2.4 C Zegelin Change fragment numbering to count down from initial Recommend no, since can't change fragmentation on fly number of fragments

48 4.1.2.4 B Dobyns Sequence control field not long enough - but no suggestion Recommend no, keep overheads to minimum of suitable length Assumption: Check sequence number and source address at destination

49 4.1.2.4 RWhite Change Dialogue Token to Sequence Number Recommend yes 50 4.1.2.4.1 A Bolea Change Dialogue Token to be random instead of Recommend no to both, random gains you nothing based

J Renfro incrementing, or starts at random value and increments. on assumption.

Assumption: Check sequence number and source address Specify sequence numbers for all stations start at O. at destination.

51 4.1.2.4.1 B Dobyns Sequence number same for all DAs or unique on a per DA Standard does permit both. basis. Assumption: Check sequence number and source address at destination.

52 4.1.2.4.1 M Fischer add ... with the retry frame control bit set to 1 Recommend yes 53 4.1.2.4.2 M Fischer frag number text Recommend yes 54 4.1 .2.4.1 J Rackowitz Increase fragment number to 5-6 bits Recommend no since this adds an extra octet and there is

T Phipps no clear justification of increased performance due to small J Renfro fragments. RWhite S Vesuna

55 4.1.2.5 M Fischer Frame body is variable length up to 2312 not 2304 Recommend no, add seperate optional fields in data frame Figure 4.1 should include the optional fields for the WEP format for IV, ICV information (IV,ICV)

56 4.1.2.5 B Dobyns Where did 2304 come from? Recommend no, this is the year that an IR PHY will be a practical WlAN solution.

Submission Page 6 of 12 Simon Black, et. aI.

Page 7: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE PS02.11-95/66 4 i

( Tag j Section I Auth()(' I Proposal I Recommendation

57 4.1.2.6 S Vesuna CRC Flag, section needs Mher work, consult references. A Bolea M Fischer E Geiger G Smith TomT

58 4.2 J Renfro Move duration field Recommend no, duration field must stay in fixed position (to allow easy hardware implementations). Only other possible place is after address 1, but this is messy since it ends up between address 1 and address 2.

59 4.2.1.1 A Bolea RTS always sent to AP in an infrastructure network, what Recommend no, since RTSICTS handshake is atways J Kubler about peer-peer? carried out with the AP since this is the optimum way to P Brenner (E) communicate the NAV to all stations in the SSS

60 4.2.1.1 M Fisher Rename DAJSA in RTS RAlTA, then add clarification text Replace terms, but text is less clear and needs more work 61 4.2.1.1 RWhite Define frame control field for all control frames in 4.2.1 Recommend yes, despite maintenance issue

Fischerrna 62 4.2.1.2 G Smith CTS should contain source, Recommend no, probability of error is extremely small (not

worth six bytes of overhead) 63 4.2.1.2 M Fischer Change DA to RA in CTS. Also clarification text on RA from Recommend yes

Fischerrna TA in previous RTS R White (E)

[: 4.2.1.2 J Rosdahl SA in CTS for Network Management Recommend no, additional 6 octets overhead per exchange, could keep track of RTSICTS pairs, only useful in ad-hoc cases (where you don't hear the RTS).

65 4.2.1.2+ o Johnson Power Control Flag 66 4.2.1.3 G Smith Add SAtoACK Recommend no, since ACK can't arrive out of sequence.

J Rosdahl

67 4.2.1.3 M Fischer Change DA to RA and add clarification text Recommend yes Fischerma

-- I

Submission Page 7 of 12 Simon Black, et. aI.

Page 8: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag ! Section ! Author ! Proposal I Recommendation

68 4.2.1 .4 C Zegelin SID missing from Poll Replace Duration with SID in Poll make changes RWhite throughout section 4 to diagrams to show additional use of T Phipps (E) this field M Demange (E) G Sherwood (E) A Bolea (E) W Diepstraten (E) T Baumgartner S Vesuna J Rosdahl Miceli (E) J Kubler J Renfro

69 4.2.1.4 T Baumgartner CF-Poll bit - where is it Became CF-Poll sub-type (data type) 70 4.2.1.4 M Fischer Suggest name to PS-Poll Recommend yes

Fischerma Change address SA to T A to bring in line with above changes to control frames

i Add SID I

71 4.2.1.4 TomT Need to define CF-END control Recommend this frame format J Rackowitz (E)

Frame control Reserved Duration RA TA CRC

TA would be BSSID, RA would be broadcast 72 4.2.2 R White (E) Change data frames to asynchronous data frames Recommend no, comment 17 already removed asynch

from asynch data (since data type frames can also carry tbs data)

Submission Page 8 of 12 Simon Black. et. aI.

Page 9: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

MArch 1995 Doc: IEEE P802.11-95/66 I Tag I Section I Author I Proposal I Recommendation

73 4.2.2.1 C Heide Sequence control field instead of sequence number and Recommen'd yes, consistency J Rosdahl fragment number Fischerma S Vesuna E Geiger J Kubler B O'Hara (E) G Sherwood (E) J Rackowitz (E) J Renfro (E) Tom T (E) o Bagby

74 4.2.2.1 C Heide Remove BSS 10 from address 3 in To/FromDS=O Recommend no, need to verify that frame is from your BSS - consider broadcast

75 4.2.2.1 T Baumgartner Dialogue Token now sequence number, move address 4 Recommend no, since address4 only in one case (to/fromDS =1) keeps sequence Control field in a fixed _place

76 4.2.2.1 M Fischer Sequence control Recommend yes, with minor rewording. RWhite First part is good clarification - yes to all sentances, but P Brenner replace initiating with originating in last sentance (even

clearer)

Frame body - should not include Iv/ICV. These are seperate optional fields in the data frame. Frame body contents not zero if subtype OOxx (positive logic)

add text ... for CF control purposes, but ... - yes

NAV vector update sentance - yes n 4.2.2.1 J Renfro Allow Null messages to be sent at any time (not just Good idea, but all tied up with the reorganisation of

during CF period), useful for power saving frame types - could get this by sending a data frame with zero length data. Usage also needs to be tied up with section 5 - this is only the frame type definition section, not usage

78 4.2.2.1 RWhite Seperate sections for data subtypes Recommend no, Data frame format constant for sub-type. Usage rules should be defined in section 5.

79 4.2.2.1 RWhite Pointer to frame control definitions Recommend no, all applicable so lust add section pointer 80 4.2.2.1 RWhite Frame usage paragraph Not in this section, needs pointer to section 5. 81 4.2.3 J Rackowitz (E) Define element type codes Recommend add pOinter to Section 4 .~~itori~ __

Submission Page 9 of 12 Simon Black, et. aI.

Page 10: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag I Section ! Author I Proposal I Recommendation -:J

82 4.2.3 A Bolea Swap BSSID and DA in management frames to make Recommend yes J Rosdahl consistent with data frames. RWhite E Geiger M Fischer B O'Hara (E) J Renfro (E) P Brenner (E) W Diepstraten (E)

83 4.2.3 A Bolea Three issues: Recommend yes to first comment: Represent mandatory information (both fixed length and

Fixed fields rather than elements. variable length) as fixed fields in management frame formats. Use elements for optional information.

Keep elements and make short timestamp 0 so that it comes out in the same place - effectively yes from above. Recommend delete weight (no longer used), and define

channel sync information Weight field has gone, channel sync information should use correct element names

84 4.2.3 C Heide Add management frame descriptions for Recommend yes: TomT Connection request J Rackowitz (E) Grant connection Need defining.

End connection

85 4.2.3 L Hamilton Draw out each management frame Recommend yes - required. P Brenner (E) W Diepstraten (E) J Rackowitz (E)

86 4.2.3 J Renfro Fixed frame for each management type rather than Recommend yes o Bagby elements Represent mandatory Information (both fixed length

and variable length) as fixed fields in management frame formats. Use elements for optional information an protocol extensions. Such elements can appear in any order.

87 4.2.3 RWhite Subsection for management frame type Recommend yes. needs completing 88 4.2.3 RWhite Define frame control field in all management frames Recommend yes, do this globally for management frame

type since frame control field same for all management sub-types

Submission Page 10 of 12 Simon Black, et. aI.

Page 11: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

~;

March 1995 Doc: IEEE P802.11-95/66 IJ3i I Section ! Author I Proposal I R~ommendation

89 4.2.3 T Phipps Management frames not fragmented Recommend no, cannot guarantee length of management frame will be shorted than fragmentation threshold.

90 4.2.3 P Brenner Add broadcast BSS 10 for management frames. Recommend yes •

J Pan Ian (E) I

Add bullet c)

In probe management frames, the BSS 10 shall either be a specific ass 10 or the broadcast BSS 10 as defined in the procedures specified in section 7.

91 4.2.3.1 Joe Kubler Delete weight Recommend yes, no longer required J Hayes I

T Phipps Channel sync information replaced by hop parameters Recommend yes, but I

W Diepstraten which is an ordered set {pattern, dwell time} (set, index not Hop time replaced by dwell time (since hop time also I

D Bagby required). contains time stamp which is redundant since it also A Bolea appears in the frame elsewhere. J Kubler Set and index not required since pattern and the frequency J Hayes you are listening to give you all the information you need to S Black get in sync.

92 4.2.3.1 J Hayes Which timestamp in beacon -long or short Recommend that long timestamp be removed, o Bagby therefore beacon contains only short tirne!tump. J Hayes

93 4.2.3.1 J Renfro Distinguish between ad-hoe and infrastructure beacons Recommend no, . Beacons are the same since differences are optional elements (TIMs). NB weight element that is mentioned is now obsolete

94 4.2.3.1 S Black Contents of beacon Recommend revisited In the light of the fixed management frame formats decision, contents a usfull list though

95 4.2.3.11 S Vesuna Reference to privicy_ alBortihm list Defer for section 2 in~ut 96 4.2.3.12 John Hayes Reference to authentication - identity assertion Defer for section 2 input 97 4.2.3.3 P Brenner Add new element to give disassociation reason Recommend no, can't enumerate all the reasons for

disassociation 98 4.2.3.4 C Heide Association request must contain CF-awareness Flag, check with section 7 folks

indicator 99 4.2.3.4 C Heide Association request must contain info to negotaite Flag, check with section 7 folks

max age of AP buffer data. 100 4.2.3.4 J Kubler Sequence element Recommend no, insufficient detail in comment 101 4.2.3.4-7 W Oiepstraten Required information in association and reassociation Flaa, check with section 7 folks 102 4.2.3.5 C Heide Remove status from association response Flag, awaiting section 7 input

--

Submission Page 11 of 12 Simon Black, et. al.

Page 12: Doc: IEEE P802.l1-95/66 IEEE P802.11 Wireless Access ... · Doc: IEEE P802.l1-95/66 Abstract: This Document P802.11-95/66 represents the output of the sub-working group of the MAC

March 1995 Doc: IEEE P802.11-95/66 I Tag I Section I Author I Proposal I Recommendation 1

103 4.2.3.6 A Bolea Remove reassociaiton - always use association Flag, awaiting section 7 input I

104 4.2.3.7 S Vesuna Reassociation contains new SID Flag, awaiting section 7 input, but likely I

105 4.2.3.8 TomT Probe request contains ESS 10 Recommend yes 106 4.3.2.9 J Renfo Distinguish between probe in infrastructure and ad-hoc Recommend no, not necessary since all differences are

optional elements 107 4.2.3.9 TomT Short timestamp in probe, not timestamp Recommend yes, but wait for section 7 input.

;.-:"::.-.--:--;<.

a1 4.3 J Hayes Allow Data-Data exchange Recommend yes for both T Phipps Allow individual ATIM J Pan ian (E)

a2

Submission Page 12 of 12 Simon Black, et. al.