Re: stds-802-16-tg3: Contention Bandwidth Request for OFDM
Subbu,
I reran the simulations this morning using 1 millisecond frame duration
instead of 5 milliseconds. Using the 6 MHz channels, and a guard fraction
of (1/8)=0.125, this results in an OFDM symbol duration of
(1+.125)*(7/8)*(256/6e6) = 42 microseconds
Thus, there are only
(1 millisecond/42 microsecond) = 24
OFDM symbols per frame. Assuming that each frame is identical, and because
each contention slot requires two OFDM symbols, provisioning the minimum of
one contention slot per frame, the lowest possible contention allocation is
therefore
2/24 = 8.33%
of the symbols allocated to contention.
I ran focused contention with code length = 4, S/AWGN = 15 dB. Comparing it
with the code-length 4 curve of Figure 6 in our contribution, I found the
results to be just a "hair" worse. (The biggest difference was at the last
data point, x=0.4; the value increased from 4.85 frames to 4.97 frames).
I believe that this "hair" increase is explained by the reduction in
contention allocation from 10% as in Figure 6, to 8.33% in the new
simulation. Apparently, the reduction in frame length from 5 milliseconds
to 1 milliseconds had no effect.
Let me know if you're interested in any other channel bandwidths or FFT
sizes, which would change the OFDM symbol duration and thus the number of
OFDM symbols per frame.
In the meantime, we're going to run the 1-millisecond frames with slotted
ALOHA, study your other comments, and see if we can simulate the "controlled
contention" you suggested. Thanks very much for your work on this.
Jerry
on 02/01/14 12:01, Subbu Ponnuswamy at subbu@malibunet.com wrote:
>
>
>> -----Original Message----- From: Jerry Krinock
>> [mailto:jkrinock@radiacommunications.com] Sent: Monday, January 14, 2002 7:36
>> AM To: Subbu Ponnuswamy; Mike Paff; Manoneet Singh; Lawrence Fung; Vincent
>> Tien; Arvind Lonkar Subject: Re: stds-802-16-tg3: Contention Bandwidth
>> Request for OFDM
>>
>>
>> on 02/01/13 21:51, Subbu Ponnuswamy at subbu@malibunetworks.com wrote:
>>
>>> Hi,
>>>
>>> I have some comments/questions on your bandwidth request proposal.
>>>
>>> In general, I think it is an interesting idea and should be discussed. Of
>>> course, we need to define additional MAC/PHY interfaces to handle this kind
>>> of BW requests. My background is MAC/IP/QoS, not PHY. So, I am assuming you
>>> have addressed all the PHY-related implementation issues.
>>>
>> Actually, my background and that of most of my co-authors is on the PHY side;
>> however we did take a stab at defining additional MAC/PHY interfaces; we
>> wrote these in sections 6.1 (page 17) and 6.4 (page 20) of the contribution
>> <http://ieee802.org/16/tga/contrib/C80216a-02_12.pdf>. We'd appreciate some
>> comments on this from other MAC experts.
>>
>>> Have you looked at allowing both "slotted ALOHA" style and "focused
>>> contention" style BW requests in the same system (controlled by the BTS
>>> scheduler, using the "controlled contention" mechanism)? Or may be allowing
>>> both, but not simultaneously. If the benefits of the focused contention are
>>> only under "heavy load" (I interpret this as the higher number of active SSs
>>> with certain traffic patterns, as the BW request contention occurs only when
>>> there are more than one SS), the BTS MAC can use some measure to "switch
>>> over" from one contention mechanism to the other dynamically? 802.16 also
>>> supports "controlled contention", where the BTS may allocate contention
>>> slots to be used for BW requests by specific multicast groups (of SSs). The
>>> same mechanism could be used to support a mix of "slotted ALOHA" and
>>> "focused contention".
>>>
>> No, we did not consider having the BTS switch dynamically between "slotted
>> ALOHA" and "focused contention", however it sounds like a good idea, and I
>> work on simulating this. I was just wondering, since you wrote "controlled
>> contention" in quotes, is there a reference describing this somewhere, which
>> I should study, or did you just think it up yesterday?
>>
>
> I used the term in quotes because 802.16 does not use that term, but a similar
> concept is described for Multicast Polling in IEEE P802.16/D5-2001. Although
> the intention of multicast groups in 802.16 is to support polling specific set
> of SSs, the same concept could be used to support slotted ALOHA and focused
> contentions in 802.16. All we need is two multicast groups.
>
> [However, it is not something that I came up with. 802.11e (QoS mods to
> 802.11) uses the term "controlled contention" for a similar mechanism for
> sending BW requests in the UL]
>
>> It seems easy to implement. In any case, the DL-MAP will specify the
>> contention window (group of OFDM symbols used for contention). To implement
>> "controlled contention", the DL-MAP will instead specify *two* such windows,
>> one for slotted ALOHA and one for focused contention. One possible policy
>> would be to always set one of these to null, forcing the other to be used.
>> However, if the system contained some SS which were not capable of focused
>> contention, then, when switching to focused contention under heavy traffic,
>> the BTS could leave an appropriate number of slots open for slotted ALOHA, to
>> accomodate the SS which were not capable of focused contention. Is this what
>> you had in mind?
>>
>
> Yes, this is what I had in mind. Basically the BTS can partition the
> contention window into two sets one for slotted ALOHA and the other for
> focused contention and either of them may be null. The slotted ALOHA slots
> will be used by SSs that are not capable of or not configured for focused
> contention.
>
>>> Have you done simulations for frame sizes other than 5ms, esp. lower (e.g.,
>>> 1ms, not unreasonable for > 5 GHz systems). We have done some simulations
>>> using about 1ms frame size and 4% OFDM symbols allocated to contention BW
>>> requests (including preambles, i.e., 2 OFDM symbols per request). This is
>>> equivalent to your 10% contention slots simulation with 5ms frames, in terms
>>> of the number of contention slots per second. Our preliminary simulations
>>> for HTTP traffic showed fairly good scalability and delay characteristics.
>>> Do you get different results for 1ms frame size in your simulations? (I
>>> understand you are measuring delay against "the average number of new
>>> contentions per OFDM symbol")
>>>
>> No, but I shall run some today and contribute the results.
>>
>>> I am not sure what you meant by the statement "the traffic models in [8]
>>> does not address contention traffic". While the model does not explicitly
>>> address contention, as the traffic models are meant to model last-mile IP
>>> traffic, it describes simulation scenarios with self-similar traffic
>>> patterns (approximated by superposition of 4 Interrupted Poisson Processes),
>>> that would result in contention based BW requests. Self-similar models (with
>>> multiple ON/OFF sources with heavily tailed ON/OFF periods) have been shown
>>> to closely approximate HTTP traffic. It would be interesting to use this
>>> model to study the scalability of BW request mechanisms (impact on average
>>> delay as the number of SSs increase)
>>>
>> I'm going to have to re-read the traffic model [8] and digest the above
>> remarks more thoroughly. When we read the traffic model we see SS
>> transmitting on and off, but presumably most of these bursts would occur in
>> piggy-backed allocations. Are you suggesting that we use the same 4IPP
>> model, probably with a lower density, and make the beginning of each
>> transmission to trigger a contention?
>>
>
> I was just commenting on your statement on contention traffic. You have
> approached the contention traffic generation from a different perspective. I
> think it is sufficient for the purpose of this exercise. There are many
> studies on Poisson vs. Self-similar traffic [both HTTP 1.1 file transfers
> (primarily DL) and HTTP object requests (primarily UL)]. By choosing
> appropriate ON/OFF parameters (lower density), it is possible to emulate User
> HTTP request behavior.
>
> Piggybacking is still a possibility if you consider various other scenarios.
> While it is true that only one user may be using a SS in a dedicated SS
> per-subscriber scenario (referred to as Individual Subscriber model in [8]), a
> typical SS in a MTU or small business environment may have a different mix of
> UL traffic. Depending on how the UL connections are provisioned, there may
> also be TCP ACKs and control packets (a good % of packets in the UL) going
> upstream in many of these environments. While this is transparent to the user,
> some of the UL requests may be able to piggyback on these ACK packets, if they
> are provisioned to use the same connection.
>
>> Thanks very much for reading the contribution!
>>
> --Subbu
>
>> Jerry
>>
>>> regards, --Subbu
>>>
>>> ----- Original Message ----- From: "Jerry Krinock"
>>> <jkrinock@radiacommunications.com> To: <stds-802-16-tg3@ieee.org> Sent:
>>> Friday, January 11, 2002 8:54 AM Subject: stds-802-16-tg3: Contention
>>> Bandwidth Request for OFDM
>>>
>>>
>>>> Hi everyone,
>>>>
>>>> At we wrapped up the last meeting (in Austin) I presented results of
>>>> studies we had done at Radia suggesting that the contention
>>>> bandwidth-request mechanism presently in 802.16a for OFDM Mode "AL" will
>>>> perform poorly. We have since documented what we feel is a better method,
>>>> done comparative simulations, and submitted comments that it be adopted to
>>>> replace the present method.
>>>>
>>>> Because we have over 700 comments to deal with in the upcoming session, I'd
>>>> rather not do another big presentation, and it would be nice if interested
>>>> members could read some of our latest contribution
>>>>
>>>> http://grouper.ieee.org/groups/802/16/tga/contrib/C80216a-02_12.pdf
>>>>
>>>> and begin asking questions before we arrive in Finland. I'd be happy to
>>>> engage in discussion either on this list, or directly with anyone. If
>>>> anyone wants to see simulation results with different scenarios or
>>>> assumptions, I'd be happy to run them.
>>>>
>>>> -- Jerry Krinock <jkrinock@radiacommunications.com> Radia Communications
>>>> 275 N. Mathilda Suite A Sunnyvale, CA 94086 phone/voicemail: 408-830-9726
>>>> ext 239
>>>>
>>>>
>>