doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 1 H²CF: Hiperlan2 Hybrid Coordination Function; Ideas on coexistence of H/2 and a-e under the e HCF Baruch Altman CommPrize July Yad Harutzim 10 Kfar Saba, Israel Tel: Fax:

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 2 Presentation Agenda Problem –Coexistence –H2 & a-e Potential HCF mechanisms –Contention Control Interval –Traffic Specification QoS info element –Other parameters –Open e issues which may impact Solution H²CF #1 ( HC in H/2 AP) Solution H²CF #2 ( HC in a)

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 3 Problem definition Goal of this presentation: Propose initial ideas on how to make the H/2 and e coexist under the proposed e HCF mechanism, Thus revealing the H²CF

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 4 H/2 & e H/2 is a controlled frame –Frame expected to start every 2ms exactly –The frame starts with data (such as network data and frame mapping) which is used by MTs to learn about the network as well as about their specific uplink and downlink timeslots Working assumptions –The H/2 AP can allocate empty timeslots, or otherwise dedicate the timeslots for traffic, as long as it is given its time for transmission of frame control every 2ms –Q: The HCF is based on EDCF. So, are the existing EDCF coexistence proposals sufficient for HCF too?

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 5 Controlled Contention Controlled Contention (9.10.4, ) –CC is only used for Reservation Requests & RR feedback? Still, in this special case of H/2 AP, can the H/2 network be allowed to transmit whatever it wants and the network will ignore? –The length of the Duration field of the Controlled Contention Interval is 2 octets, => 2^16 ( 65536µs >> 2ms of the max H/2 frame, which makes it usable )

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 6 Controlled Contention Contd –Controlled Contention Interval (CCI) can be set with a priority mask & Probability threshold, to limit contention to specified priorities only. However, using the existing priorities is not good enough as there are only 8 (& suitably a 1 octet mask). These priorities may be used by every station, not only H/2 AP and so they will also contend. Therefore, could we use this priority combined with other fields to make it impossible for strict 11e stations to contend, yet make it possible for H/2 APs? –E.g., use priority mask 0 (indicating a feedback frame), & Feedback Count also 0 (seemingly contradicting) –Or, new use of the reserved octet –Or, request to change from a bit map mask to a TCID field (2^8 TCs instead of 8), but this will have to be matched with similar change throughout the Draft, to increase the overall number of TCs.

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 7 Controlled Contention Contd Additionally, set the probability (PP) to 255 to minimize the probability of other stations with same priority to be contending to 1/255. –Q: 255 seems like the right value, but on Pg. 78, #10 this seems to rather allow sending all messages than limit all, so which is right? Still, not sure how it all works. Under the same mask can be, for example, periodic and continuous TCs (same priority). This means that two different types of services will then contend?

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 8 TS QoS Element Traffic Specification QoS element ( ) –Alternatively, a new Info Element may be requested for j, similarly to those reserved for d. One such new elements shall be used to define the H/2 AP QoS parameters, and initially be quite similar to this QoS element (subset of it). –In the figure (42.7) there is a field called TCID (2 octets). In the text below it is referred to as the QoS Control field. Ok. So, TCID here is also only 3 bits, with the 8 options only that can be used by any station. Unless we use some kind of a combination with the other fields to uniquely identify the H/2 AP. –Source address, destination address: These 6 octets each fields may be used to distinguish the H/2 AP from other stations. This is feasible, for example, when saying that the source address and the destination address are both set to the same value. Or, even more specifically, when both are set 0 (or a range of such values).

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 9 TS QoS Element Contd –TS Info field – the Traffic Type should be set to 1 to indicate periodic; Ack policy – dont care, or may use the reserved for future use to indicate H/2 AP periodic; The Delivery Priority, again only 8 options which may be used by any station. So dont care for H/2 AP? Or use the highest? –Inactivity Interval should be set to 0 to inhibit the inactivity for periodic –Polling Interval should be set to indicate 2ms. This field is in Time Units. To relieve the H/2 AP from the need to understand other messages it is better to have this field set to some pre- defined value which is prohibited by other stations, or, if we find a method to make H/2 APs QoS elements distinguishable, then always have TUs mean µs.

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 10 TS QoS Element Contd –Nominal MSDU size (2 octets)? Irrelevant? –Minimum Data Rate (2 octets) - irrelevant –Mean Data Rate (2 octets) - irrelevant –Max Burst Size (2 octet) – irrelevant –Delay Bound (1octet) – irrelevant –Jitter Bound (1 octet). Should be set to 0 or almost 0 to ensure Polling Interval (2ms) H/2 frames. Measured in TUs, so again, for H/2 elements should always be interpreted as if in µs (or even 400 nanosecs units such as the H/2 standard defines?). Alternatively, could be irrelevant, because if the element is identified as H/2 related, then the QoS is known to be absolute, so that automatically a 0 jitter bound can be assumed.

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 11 QoS Control field QoS Control field ( ) –Can be used to signal the queue size or requested duration in RR frames or WSTA null frames ( units of 128 octets or 16µs respectively ) –Includes TCID which signals the user priority (2^3 = 8 TCs only) The H/2 AP could transmit this frame to signal it needs allocation –Transmit when? The H/2 AP needs some e CSMA awareness Needs to ensure that the allocation will be on the 2ms mark. How? The HCF needs to allocate the requested duration –Do we need a new TCID for H/2 APs (again, a TCID > 8) so that the HCF can guarantee to it the allocation? If yes, this is an increase in the potential overall TCID throughout the Draft.

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 12 HCF parameters –dot11MediumOccupancyLimit ? Set it to the maximum time allowed for transmission (I.e. (2ms - ))? –dot11MaxDwellTime ? Same only for frequency hopping (therefore irrelevant to us)? –Station type Do we need to reserve a type for H/2 APs (in the same context as CF-pollable etc. stations are defined)

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 13 HCF parameters Contd TCA and TCID Do we need/want a new Traffic Class to describe a H/2 AP? (I.e. high priority, 2ms periodicity, 0 jitter, …?) Or is it enough to have it specified in a TxOP messages sent by the AP. AID (Association ID) in the TCA – if the H/2 TCID is unique, thn no need for a special AID

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 14 Open issues? Issues? – , Pg. 75: OPEN ISSUE : In the case of a TC with an accepted TSPEC which specifies periodic traffic type, with non- zero parameter values for both Polling Interval and Jitter Bound, the non-receipt of a periodic CF-Poll at intervals of Polling Interval plus/minus Jitter Bound is also a detectable non-occurrence of an expected reception which can have important consequences for QoS within the effected TC. It is appropriate to add the rules under which the ESTA can, after non-receipt of some number of these expected periodic polls, use a higher priority means of obtaining medium access during the CP to continue the periodic transmissions for this TC. This case was not covered in previous proposals because there was not sufficient specified relationship between TSPEC paarameters and TXOP timing to detect this situation. Network Management

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 15 H²CF Operation Option 1 (HC in H/2 AP) HC is implemented in the H/2 AP The HC is used for managing the e network, if it exists –It is a SW management package Some increased memory requirements MIBs? –The H/2 AP will also implement some PHY Carrier Sense (CS) to detect that a a exists No real PHY change? Or need to add timer counters? Anything to be done at the H/2 SW DFS level?

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 16 H²CF Operation Option 1 Contd The HC will dynamically allocate time for the H/2 traffic –Use traffic requirements provided to it directly by the co-located H/2 AP about how much allocation is best for the H/2 –Use Contention Control To silence all e contenders, allowing only H/2 traffic To be repeated every 2ms (start a little earlier as guard time) to ensure 2ms H/2 frames Minimum CCI length is for BCHs & ACHs & RCHs per the sectors of the H/2 The open questions raised above about the e parameter values must be answered, perhaps changes to the e may be needed

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 17 H²CF Operation Option 1Contd The H/2 AP will dynamically allocate time to its traffic –Use info provided to it directly from the co-located HC about how long the CCI was allocated –RCHs location Either in the same CCI as its BCHs, only this could be quite short, so perhaps even immediately following the ACHs Or, the RCHs will be mapped to the beginning of the next expected CCI. So a H/2 CCI will start not with BCHs, but with RCHs of the previous H/2 frame. The traffic will be held between the H/2 BCHs/ACHs/data traffic and their RCHs. HC handover between existing e and this H/2 HC –Use the e TBD handover mechanism so that its always at the H/2 AP –When the H/2 is shut off, handover HC back to existing e network, if HC exists there

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 18 H²CF Operation Option 2 (HC in a) The e HC/CC shall detects that a H/2 exists –Is PHY CS enough? –802.11h DFS detecting H/2 BCHs (SW)? –Or, the H/2 AP will detect the a and transmit a e TS QoS element H/2 need not implement the e contention mechanism because we can decide that it will always be top priority, and that the HC will allocate from time to time a CCI only for H/2s contenders (as discussed above, limiting all other contenders) And/Or, could the H/2 AP utilize a new IFS, (shorter than PIFS, longer than SIFS)?

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 19 H²CF Operation Option 2 Contd The H/2 CSMA will be: –When coming to a new channel, detect its occupied by a a using PHY DFS and MAC (recognizing the difference in preamble?) H/2 AP needs to implement some MAC level DFS –If wanting to coexist in that channel, wait till xIFS (new?), then transmit TS QoS element Using an implicit association (I.e. by sending this message). Is this an exception to the current e proposal? H/2 needs to implement xIFS detection and a preamble, and a (few) specific e TS QoS element message(s) requesting, at this stage, a minimal time for its own traffic (say 1ms?); Or, use as suggested a new & similar element

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 20 H²CF Operation Option 2 Contd –The H/2 AP will then try to detect a pattern of repetitions of silence period for the requested time (say twice) If detects, then during the following silence period (the 3 rd in this example), the H/2 AP can start operating its network. Else, I.e. if not detecting the pre-determined repetition of silence periods for the requested duration, then the H/2 AP will conclude that the HCF cant work (not an e, or other reason) –The H/2 AP will transmit info to allow dynamic CCI allocation for its contemporary traffic Could send e TS QoS elements (or, again, new similar ones), with updated duration; Or, could send e RRs After sending such update messages, the H/2 AP should listen on (one?) expected CCI to determine what new duration has the HC allocated Q: when should the H/2 AP send these messages so that the e HC will listen for it? (The HC should not listen on the H/2 traffic conducted during the CCI).

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 21 H²CF Operation Option 2 Contd –The H/2 AP will start every expected transmission period (at the expected intervals) with yIFS, to ensure that the e HC still allocates CCI time for it If yIFS is vacant – continue with own traffic Else, I.e. if yIFS has signal in it, go back to start of algorithm and try to send a new access TS QoS element –The e HC will respond to the requested H/2 AP TS QoS by Maintaining the exact requested periodicity To end/nullify these allocations, transmit (something) at the yIFS time where the H/2 AP expects its CCI. To shorten allocated periods it could either nullify as above, so that the H/2 AP will initiate new allocation request, or wait till the H/2 AP initiate such requests and then allocate less than the requested period. This mechanism goal is to minimize the inter-standards messaging. Q: When should the e HC listen for new H/2 AP TS QoS?

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 22 H²CF Operation Option 2 Contd –RCH location etc. Same as in option 1. The ordering of the H/2 frame has the same options.

doc.: IEEE /402r0 Submission July 2001 Baruch Altman, CommPrize Inc.Slide 23 H²CF Summary The proposal offers initial examination of H2CF: H/ a-e coexistence under current e HCF Three HCF mechanisms discussed: –Controlled Contention –Traffic Specification QoS element –QoS Control field Two H²CF options discussed: –HCF at the H/2 AP –802.11e HCF detecting H/2 AP Open issues still require answers