doc.: ieee 802.11-01/402r0 submission july 2001 baruch altman, commprize inc.slide 1 h²cf:...

July 2001

Baruch Altman, CommPrize Inc.

Slide 1

doc.: IEEE 802.11-01/402r0

Submission

H²CF: Hiperlan2Hybrid Coordination Function;

Ideas on coexistence of H/2 and 802.11a-e under the 802.11e HCF

Baruch AltmanCommPrize

July 2 2001

Yad Harutzim 10 Kfar Saba, IsraelTel: +972.9.7645831 Fax: +972.9.7667388

[email protected]

July 2001


Slide 2

doc.: IEEE 802.11-01/402r0

Submission

Presentation Agenda

• Problem– Coexistence– H2 & 802.11a-e

• Potential HCF mechanisms– Contention Control Interval– Traffic Specification QoS info element– Other parameters– Open 802.11e issues which may impact

• Solution H²CF #1 (802.11 HC in H/2 AP)• Solution H²CF #2 (802.11 HC in 802.11a)

July 2001


Slide 3

doc.: IEEE 802.11-01/402r0

Submission

Problem definition

Goal of this presentation:

Propose initial ideas on how to make the H/2 and 802.11-e coexist under the proposed

802.11e HCF mechanism,

Thus revealing the H²CF

July 2001


Slide 4

doc.: IEEE 802.11-01/402r0

Submission

H/2 & 802.11e

• 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 802.11 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?

July 2001


Slide 5

doc.: IEEE 802.11-01/402r0

Submission

Controlled Contention

• Controlled Contention (9.10.4, 7.2.1.9)

– 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 802.11 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)

July 2001


Slide 6

doc.: IEEE 802.11-01/402r0

Submission

Controlled Contention Cont’d

– 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.

July 2001


Slide 7

doc.: IEEE 802.11-01/402r0

Submission

Controlled Contention Cont’d

• 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 9.10.4.1 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?

July 2001


Slide 8

doc.: IEEE 802.11-01/402r0

Submission

TS QoS Element

• Traffic Specification QoS element (7.3.2.15)

– Alternatively, a new Info Element may be requested for 802.11j, similarly to those reserved for 802.11d. 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).

July 2001


Slide 9

doc.: IEEE 802.11-01/402r0

Submission

TS QoS Element Cont’d

– TS Info field – the Traffic Type should be set to 1 to indicate periodic; Ack policy – don’t 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 don’t 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 802.11 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.

July 2001


Slide 10

doc.: IEEE 802.11-01/402r0

Submission

TS QoS Element Cont’d

– 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.

July 2001


Slide 11

doc.: IEEE 802.11-01/402r0

Submission

QoS Control field

• QoS Control field (7.1.3.5)

– 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 802.11e 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.

July 2001


Slide 12

doc.: IEEE 802.11-01/402r0

Submission

HCF parameters

– dot11MediumOccupancyLimit ?• Set it to the maximum time allowed for 802.11

transmission (I.e. (2ms - <guard time>))?

– 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)

July 2001


Slide 13

doc.: IEEE 802.11-01/402r0

Submission

HCF parameters Cont’d

• 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

July 2001


Slide 14

doc.: IEEE 802.11-01/402r0

Submission

Open issues?

• Issues?– 9.10.1.2, 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”

July 2001


Slide 15

doc.: IEEE 802.11-01/402r0

Submission

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 802.11e

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 802.11a exists• No real PHY change? Or need to add timer counters?• Anything to be done at the H/2 SW DFS level?

July 2001


Slide 16

doc.: IEEE 802.11-01/402r0

Submission

H²CF Operation Option 1 Cont’d

• 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 802.11e 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 802.11e parameter values must be answered, perhaps changes to the 802.11e may be needed

July 2001


Slide 17

doc.: IEEE 802.11-01/402r0

Submission


• 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 802.11 traffic will be held between the H/2 BCHs/ACHs/data traffic and their RCHs.

• HC handover between existing 802.11e and this H/2 HC– Use the 802.11e TBD handover mechanism so that it’s always at the H/2

AP– When the H/2 is shut off, handover HC back to existing 802.11e

network, if HC exists there

July 2001


Slide 18

doc.: IEEE 802.11-01/402r0

Submission

H²CF Operation Option 2 (HC in 802.11a)

• The 802.11e 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 802.11a and transmit a

802.11e TS QoS element• H/2 need not implement the 802.11e 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)?

July 2001


Slide 19

doc.: IEEE 802.11-01/402r0

Submission


• The H/2 CSMA will be:– When coming to a new channel, detect it’s occupied by a

802.11a 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 802.11e proposal?• H/2 needs to implement xIFS detection and 802.11a preamble,

and a (few) specific 802.11e 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

July 2001


Slide 20

doc.: IEEE 802.11-01/402r0

Submission


– 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 3rd in this

example), the H/2 AP can start operating it’s 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 802.11 HCF can’t work (not an 802.11e, or other reason)

– The H/2 AP will transmit info to allow dynamic CCI allocation for its contemporary traffic• Could send 802.11e TS QoS elements (or, again, new similar ones),

with updated duration; Or, could send 802.11e 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 802.11e HC will listen for it? (The HC should not listen on the H/2 traffic conducted during the CCI).

July 2001


Slide 21

doc.: IEEE 802.11-01/402r0

Submission


– The H/2 AP will start every expected transmission period (at the expected intervals) with yIFS, to ensure that the 802.11e 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 802.11e 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 802.11e HC listen for new H/2 AP TS QoS?

July 2001


Slide 22

doc.: IEEE 802.11-01/402r0

Submission


– RCH location etc.• Same as in option 1. The ordering of the H/2 frame has the

same options.

July 2001


Slide 23

doc.: IEEE 802.11-01/402r0

Submission

H²CF Summary

• The proposal offers initial examination of H2CF: H/2-802.11a-e coexistence under current 802.11e 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

doc.: ieee 802.11-01/402r0 submission july 2001 baruch altman, commprize inc.slide 1 h²cf:...

Documents

hcf slide

h2 network

coexistence of h2

h2 ap periodic

usable slide

e hcf baruch altman

h2 ap solution hcf

h2 aps