! OjL\ \ eeeeeeffffff2ffHf$lili(iiiiiiiiiiUjsjBj>sjesjsjsj(+Tentative Minutes IEEE P802.11 MAC AdHoc Committee Irvine, CA March 11, 1992 The meeting was called to order at 1:34 pm by Bob Crowder, chairman. Simon Black as recording secretary. Two presentations were heard, one from Dr. Jonathan Cheah, the other from Dr. K.S. Natarajan. Questions should be strictly limited to clarification only. Dr. Jonathan Cheah, ref. P802.11/92-2 No handouts this time, but look at 92/2, distributed last time. An analogy is in order to reduce the complexity of the MAC concept. My analogy is a traffic crossroads. Aloha is like a country road - little traffic, you cross at your own risk - you have a good chance of getting across At a town junction with greater traffic, so you introduce a junction with a stop line. You stop and look before crossing. This is like CSMA. In very heavy conditions you need traffic lights, however this can become inefficient for low traffic. This is like TDMA. I introduce several classes of device: A full head end with a wired LAN interface and wireless interface; A standalone head-end with a wireless interface only; Lastly a pseudo headend, this is a node that can take on the headend function. There is a continuous TDM signal (see past documents, but I have some amendments). Broadcast is now not close to ALOHA (relaxation on timing). Headend comes up and listens. If quiet he then broadcasts the timing structure. A node coming up listens to the timing structure. He then knows when he can ALOHA in to request bandwidth (on a demand assigned basis). You can introduce any traffic assignment algorithm, depending for example on the traffic load (this can ensure fairness). However, there is a problem due to the fixed delays involved in setting up the bandwidth. To get round this, if there is no traffic, the headend can divide the timing frame into more ALOHA slots. This reduces the delay for low traffic situations. I have increased my overhead, but it is still small. When traffic gets heavier, I can lessen the overhead at the expense of delay. I have thought about IR in this method. For IR you cannot do code (maybe possible in future) or frequency. I can do spatial or temporal. Temporal is only reliable (overlap possible in spatial). This is the basic concept that I have used. For a single head end - when it comes up it listens to see if there are other signals present (you can achieve redundancy this way). If everything is quiet (no other head ends present) the head end sets up a timing structure for minimum delay. Continuous timing ticks help in radio clock synchronization. The head end announces the frame size and position of the ALOHA slot and any other supervisory information - eg network id, or whether backbone traffic is allowed (there is a backbone attached), or whether this is a pseudo headend. This information is all transmitted in a broadcast slot. The headend can maintain traffic efficiency by adjusting the frame size and also check the signal-to-noise ratio (SNR) (for interference from other headends - for example moving pseudo headend approaching another headend). If SNR becomes too small - do a reset. Headend also maintains backbone traffic. You can also do range extension by repeating traffic through the headend. In each slot you might have supervisory, address, packet number, data and a sub-slot for receiving station ACK. There is much flexibility here. You can use the supervisory field for termination, ack request, pause, stream setup, etc.. You can dream up whatever you like. The sub-slot can be used for ACK (without requesting another bandwidth assignment for acknowledge). You could also request specific packets for retransmission. You can also use this for stopping transmission temporarily whilst trying to ALOHA into another headend (BSA), eg for a mobile station. You may not be successful of course, if you are then momentarily you will have two reservations, so you must close one down. Thus you can maintain a contiguous session whist moving from headend to headend. If you have a mobile headend (for example a pseudo headend in a mobile station) and this headend approaches a stationary headend. The SNR will deteriorate, so the headends checks SNR. If the SNR falls below a limit, there must be a shutdown & restart mechanism. I urge you to read my last submissions for the details. The headend has two interfaces - one is wireless, the other is tied to the distribution system. If one node communicates with another station in another BSA (ie in the ESA) the headend handles communication via the distribution system. The pseudo headend will take more power than a station, this might be an issue for adaptors in laptops. You might not allow pseudo headends in certain cases. I am sure I can achieve the "21 points" with this protocol. In the past I advocated a synchronous network, but this is not necessary. I don't want my network to behave like Malaysian fireflys ! There is information in 91/54, 91/111, 92/2. Also in a 802.4L paper (part 1 of 91/54). 92/2 contains an assessment of the protocol against the 21 points. Discussion: Chan Rapinski: How big is slot, frame, ... ? Jonathon: For future study, but satellite system uses 256 byte slot (protocol originates from satellite system). Maybe 512-or 1024 slots/frame. But this is traffic adaptive in steps (maybe three steps). Bob Crowder: What is the MAC doing when there are co-sited networks? Jonathon: If they can hear each other then the headends will sort the problem out. Wim Diepstraten: What about a node that hears two headends? Jonathon: He will communicate with one headend. Carolyn Heide: But in doing so he may interfere with communication in the other network. Jonathon: There is orthogonal isolation Wim: There will be interference - this not an ideal satellite system. Bob: In your view there can be good isolation of networks, where this is not the case there will have to be coordination between the two headends. Is this true? Jonathon: Yes. Consider a single headend - there will be blind spots in the room. I might place my station where communication is impossible. For two headends I might have some areas where the SNR is too bad for communication (if isolation cannot resolve the situation). Chan: In one aspect you are unfairly attacking Jonathan. Code division may not be adequate in some cases between headend coverage areas. This is a degradation, not a complete failure. I would like to understand the use of the codeset - do you in fact have a channelized plan? Bob: We should not talk about codes. Chan: Would you select the best channel initially Jonathon: Yes. Chan: Might you use a different channel for the ALOHA, data, etc. ? Jonathon: No, efficiency would probably drop - this is based on a simple calculation. Hooks in the MAC would not preclude this though. Christopher Flores: Don't you have to support a distributed control ad-hoc network (Functional requirement)? Jonathon: I can do this via the pseudo headend. Christopher: What happens if a head end goes down ungracefully? Jonathon: This is a network failure, things will restart. Carolyn: Something we need to bear in mind for battery operated terminals - the headend function can consume much power. Jonathon: You are only maintaining time ticks & broadcast - this is not much more power. Carolyn: But my processor cannot sleep. Jonathon: But you can pass on the function if necessary. Chan: A station that is providing the control may be using more power - this may be true, but not necessarily. Bob: I am used to dealing with things that deal with frames, we need more clarification on the structure of the frames, etc. Jonathon: Look at my submissions, but I will try and produce a more complete proposal. Bob: I would like to see one proposal that covers everything. Simon Black: I would like to see some starting parameters for frames, slots,etc. so we can do some analysis work. Wim: The time ticks - is this a bit tick or frame tick? Jonathon: As far as the MAC is concerned this will be one byte. Wim: Is this using a unique code? Jonathon: Code will be in PHY, byte will consist of identification only. Chan: If you have a small payload will you use a fixed timing parameters? Jonathon: No. Chan: How big is a slot? Jonathon: 256 bytes. Chan: If message is smaller than 256 bytes - there will be some unused channel time? Jonathon: Yes. Bob Rosenbaum: I don't think this is very productive - Jonathan designing on his feet. Should we encourage Jonathan to continue ? With some guidance. Bob C: We cannot decide this. Jonathon: To come up with an access method takes a lot of work, please if you think this is so far off, please say. Bob C: I cannot personally evaluate your proposal from what we have today. Jonathon: I will prepare another submission. Break. General Discussion: Bob C: Nat is going to present his proposal. I would like to enquire as to whether we should expect more proposals. Carolyn: Bob Rosenbaum and Dave Bagby have previously indicated that they have proposals. Bob R: We will try and put something together for Leiden. (Dave Bagby is not present) Bob C: We might discuss a closure date for new proposals. Chan: The question is whether the closure date can't be sooner than the next plenary. Bob C: We could set this as a target. Bob R: What do we wish to accomplish by setting a deadline? Would it be appropriate to say that we will consider proposals submitted before the next plenary? Chan: It might take a vote to submit a plan after the next plenary. There has to be a way of finishing. Simon: It will become more difficult to introduce new proposals as we begin to focus. Bob C: We must begin further analysis of proposals at some point. Simon: This is happening now - see my and Wim's papers submitted at this time. Bob C: When we have functional requirements we may start to analyze proposals against the functional requirements. Chan: The problem that I have is it is always easiest to be last. Wim: That's why we are all waiting! Bob C: Does anybody want to make a motion about submissions? Chan: I move that whoever has a candidate for a MAC protocol submit it to the committee ... I withdraw the motion. Christopher: Do we need a motion with a given deadline? Bob C: This is an important point. Jonathon: I will draft a motion (off line) Dr. K.S. Natarajan, ref P802.11/92-39 This is an update of my presentation given last July. I will go through the 21 points. My previous contributions are 91/74 & 91/102. This presentation is 92/39 We can consider a wireless LAN scenario, where communication can occur between stations through an infrastructure access point and possibly through a distribution system (Infrastructure based). We can then have ad-hoc networks with ad-hoc access points. Ad-hoc and infrastructure access points are introduced. Intercell isolation may be by frequency, time, space or code division (or no isolation). Intra cell isolation is via MAC control - this is a hybrid scheme with both controlled access and random access. The MAC applies to a variety of PHY's. An access point from the MAC point of view is as a scheduler - timing and synchronization, registration and data transfer. Discussion: Jim Schuessler: The scheduler resides in the access point? KS Natarajan (Nat): Yes, but this function is also present in all of the stations so they can act as an access point if the need arises. The timing structure is a sequence of frames, divided into three - broadcast, contention free and contention based. Each has a header. Broadcast is access point to mobiles. In period A - broadcast, access point can transfer information to the mobiles. This field has a header containing a variety of control, information - length, id of the access point, net id. Stations, by listening to header, know what is coming in the broadcast field. Certain stations can also be addressed. The second period in the frame is a contention free field based on a reservation scheme. Allocation information is contained in a header field. Header contains length field and details of allocations. This field is mobile to access point (a mobile is any station not an access point). At what point does the mobile station know he has received an allocation? Reservation requests are made in the contention field, then you keep listening to the header in the second field until you get a reservation. The whole structure is dynamic - so if there is no broadcast, or reservation then the whole thing is given to a contention access field. Discussion: Peter Cripps: How long might the frame be? Nat: Depends on channel speed, number of stations. Peter: My issue is that there is a frame delay involved - possibly more for retransmits. The third field is a contention field - also with a header. We assume that this is a slotted ALOHA based protocol. This field contains request messages for registering with an access point, bandwidth reservation requests and data packets. The random access protocol might be some other protocol - for example some carrier sense scheme. All traffic here is mobile to access point. In registration, a mobile transmits a registration request packet. It may be accepted - in which case it will receive a registration response packet. Isochronous services are supported by requesting bandwidth through a reservation request packet containing details of the service required. You have to send a cancellation after you're through. Overall frame length is fixed - but as small as practical, but not so small such that the overheads become significant. A+B+C is fixed, but A, B might be zero, then the frame is all C. There is a minimum required contention period - initial simulation suggests that this is 20%. This is because bursty data, reservations and registration require a rapid response. There are two modes of operation - a direct transfer mode, and a second mode via an access point (store and forward mode). Both random access and reservation are allowed in direct communication. If direct communication does not succeed after a certain number of attempts then you try communication via the access point. This is one implementation possibility. This is an overview of the protocol, now the criteria (the "21 points"): 1 - unauthorized network access impact on throughput - registration will exclude unauthorized users from accessing the network. Discussion: Bob Crowder: Are you accepting channelization for isolation? Nat: Frequency hopping. Bob: Frequency hopping is your method of channelization. Jonathon Cheah: Are you claiming that you will have priori knowledge of hopping patterns that give you good immunity to interference? 2 - peer to peer connectivity - any station can act as a basic access point supporting registration, bandwidth allocation and timing. This is an ad-hoc access point. Discussion: Nathan Silberman: How is this separated from the rest of the network - from an interference point of view? Nat: I will cover this in a later point. 3 - throughput - simulation shows that the maximum throughput approaches 87%, given a set of assumptions. Also link utilization is high and the protocol is stable under high load (because A and B are contention free). This also assumes slotted ALOHA in the contention period. This also assumes a fixed frame partition - 20% for C, 80% for A & B. Frame partitioning has an effect - throughput drops for increased contention period (as you would expect). We have to establish simulation ground rules - including realistic traffic model assumptions. 4 - delays - under light conditions the limiting factor is the contention protocol used. As the load increases then the delay caused by the reservation process is significant. 5 - Max number of stations - depends on a number of factors: peak data rate, traffic model. MAC protocol does not place any limitations. 6 - different kinds of traffic - isochronous through reservation scheme. How do the access points send isochronous traffic ? Through period A, controlled by reservation requests. 7 - transparent to PHY layer - some assumptions made in proposal for a FREQUENCY HOPPING SS PHY. DS is possible using code division. IR is also possible through access point timing information and spatial separation. This is a problem common to all proposals. 8 - robustness with respect to collocated networks - by management of FREQUENCY HOPPING patterns: assignment of FREQUENCY HOPPING patterns to access points. Discussion: Jonathon: you have to be synchronized to an access point ? Nat: you have to listen to get synchronization (priori knowledge of hopping pattern). Some simulation has been done for interference using certain frequency hop patterns. 9 - battery power consumption - various strategies. 10 - any critical delays - no. 11 - fairness of access - uses access point scheduler. 12 - capture effects - no capture phenomena in contention free intervals. Capture will improve throughput in contention interval. 13 - Priority traffic - based on scheduler. 14 - Non-reciprocal traffic - missing acks detected and recovery occurs via access point. ACKS on both contention free and contention channels 15 - Time to market - simple MAC protocol. 16 - Simple and large systems - yes. 18 - Handoff and roaming - three possibilities: access point, mobile station or mobile assisted/access point initiated handoff. Each mobile is registered to one access point at a time. 19 - Complexity of PHY - works with simple PHYs, can take advantage of complex. 20 - Broadcast - yes. 21 - Time order - yes. General Business Thanks to Jonathon and Nat for their thorough presentations. Motion #1: Any access method/protocol that will be considered by 802.11 MAC adhoc group shall satisfy the following criteria: 1) It, in the submitters opinion, can satisfy all 802.11 functional requirements; 2) It has to be submitted prior to the 7th July 1992. After this date contributions will only be considered after a >50% approval vote from the MAC subgroup. Moved by: Chandos Rapinski Seconded by: Jonathon Cheah Motion Discussion: Dale Buchholz : What about if I take pieces from other proposals. What is a new proposal? Chan: I would still ask you to submit the combined proposal by 7th. KC Chen: After July 7th all MAC proposals go through this rule? Chan: Yes. KC: How do I know I have 50% approval to submit? Bob Crowder: You still submit, then the MAC group votes. Wim Diepstraten: How do you get to convince people about the 50% - a presentation? Jonathan: No - we are short of time, to conserve resources you satisfy yourself that it meets the requirements, then submit to the MAC group members. Then MAC members will vote. Nat: List of MAC members is not firm. Bob: A lot of unanswered questions - amend for Holland. Jim Schuessler: Speaking against the motion - I want to provide an alternative, progress will be made when we choose a particular proposal and base a draft on it. KC: Any kind of proposal requires much time to evaluate - earlier proposals are at an advantage. Dale: There is a mechanism in place to progress this already. Jonathon: It would be a mistake to have a pure cut-off date that eliminates the possibility of looking at an ingenious proposal later (particularly if none of the current proposals turn out to be acceptable). Simon Black: Moves to call the question. Jonathon: Seconds. Vote to call the question: (unanimous approval) Approved: 8 Opposed: 15 Abstain: 15 Motion #1 Fails Meeting adjourned. March 1992 Doc: IEEE P802.11-92/43 March 1992 Doc: IEEE P802.11-92/43 Tentative Minutes of meeting page page \* arabic6 Irvine, CA, 11 March 1992 Tentative Minutes of meeting page page \* arabic7 Irvine, CA, 11 March, 1992 d proposal by 7th. KC Chen: After July 7th all MAC proposals go through this rule? Chan: Yes. KC: How do I know I have 50% approval to submit? Bob Crowder: You still submit, then the MAC group votes. Wim Diepstraten: How do ybo|iu@Hq~;>(,[cko8K SZ'.PXx  !'!i!m!!!!!!!!!I"Q"Y"f"""######$$"$$$ b$$$F%K%%%%%%&&&' '^'c'''''e(i((((( )))))))) *1*z-----22222 3&39::F:I:_:b:::;;;B<E<(B5B>BrBvB{FFF?HyHHHHHH.I5IoIsI{I}IIIII;JCJJJKKOK]KKKUL bULYLLLfMrMMMM N N NNNNNNNNNNNNNOOO =%Mc 4;ta>boi@q;([k8S'Px !i!!!!!I"Y""½⸳$$$$$$$$&$&$&$& $ &$&$&$"$'$'$ $%$hB"####$$$$$)%F%%%%&'^'''e((( ))))* *1** ,,z---M.O.10O1(2222 3z3|345U677/9y99:F:_:: ;";;;B<l<n<4>>D??@@A(B5BrBC!CVCvCC1D$$$$$"$$$&$$$$$Q1D^DDEAEELFcF{FFFJGGGAHyHHH.IoI{III;JJKOKKULLfMMMM N N NENGNlNnNNNOOOOĿĿ$$!$$$$$$$ $$$"$$$.:main body textrunning footer document list hotel namesreturn addressP3 memberlistquasi top for addinghanging main body te Sub titletable constructoutlinefigure constructagenda item number temp doc listdestination in temp IBIS level 0 IBIS level 1 IBIS level 2 IBIS level 3 IBIS level 4 IBIS level 5 IBIS level 6 IBIS level 7 meeting listfinancial statement Heading Blockname and phone list Mail List Main title motion text motion movesmotion resultsagenda sub-itemagenda main itemdiscussion text report titletext main textk                       c  !! xH$ @ @x  00H$@@ A <  # ! % 9! 0 M 5pP ` @P"$&)@@ @!@2 # @0p @ D ,p@ P !$`'@@ @!@#  !@`x%  p pxx000000 p000  p@ 00 p@ 00&p@ 0)p@ 07 @ @ @xII I!I   @x @ @0@h$   @ @ "    @ P(!   PP""  !#$ %P& ')B  !"#"$%&'&)MO '4AKMz *'N$ULO()*"1DO+,-$ Chicago 1Courier Script PFinney LosAngeles Bookman"Helvetica-Narrow PalatinoZapfChancery Norton Parker "AvantGardeNew Century SchlbkDotsBlack Shadow Aberdeen Boutn CanterburyDemographics Zodiac TileOld English Metropolis Arabic-12HamIcon Moscow RavennaVice Vienna RussianPskov Bombay JacksonvilleOldStyle Mos Eisley Cupertino Florence Camelot KawasakiCrete Vladimir Beneventan Broadway ELaserLondon Garamond 3B Garamond 3 Bold Playbill FantasteZebra ShadesToulouseLautrec Embossed QuantumBlackChancery HarringtonBODIDLYboldMira MT ExtraAndesite TrueTypeUpperEastSidePolo-SemiScript Rudelsbergp!!PostScript PrinterLPT3:PSCRIPTPostScript Printer#5#6#"F?'0@X  odxx,;]x N] =AyL4=Rm3vRR !#=/88y*:E:E? K>IEEE 802.11 MAC 03/92 MinutesSpectrix Corp. Vic Hayes