Hello Mathieu, Thanks for replying. I got things clearer now that I've read a couple of papers about 802.11e. I'm not an 802.11e expert. I think the behavior you implemented is correct. Flows not accepted by the scheduler must not use the EDCA slots in the CP, as those are reserved for legacy (non-802.11e) nodes.
I've been having a problem where I keep getting CAP Proportion error messages. It would be ok if I was requesting a considerable number of flows. But no, I get it when I try to request 2 flows. The first flow is accepted but the second is refused due to CAP Proportion error. You can replicate it with the attached script. Its a modification of the test-80211e.tcl. Instead of 3 nodes, it's only 2 nodes. Can you please run the script and verify if you get the same result? Thank you! Best Regards, Pedro Fortuna INESC Porto On 8/14/06, mathieu lacage <[EMAIL PROTECTED]> wrote:
hi pedro, On Fri, 2006-08-11 at 19:53 +0100, Pedro Fortuna wrote: > Hello Mathieu, > > Sorry for bothering you again. I have a question which might have > more to do with the 802.11e standard, but maybe you can enlighten me a > bit. Im using your 802.11e implementation in NS2 to setup a scenario > where a number of VoIP flows is exchanged between the QAP and a bunch > of nodes. > > Each flow is configured with the exact same TSpec: > # set TSpec > set tspec [new TclTspec] > $tspec set-minimum-service-interval 0.0 > $tspec set-maximum-service-interval 0.0 > # ms > $tspec set-delay-bound 0.125 > # bytes > $tspec set-nominal-msdu-size 80 > # bytes per second > $tspec set-mean-data-rate 8000 > $tspec set-peak-data-rate 8000 > > But when running the simulation, only the first flows are accepted (1 > or 2 flows). The subsequent flows are refused due to CAP proportion > being too big. > I understand that during the CP, the QAP is able to provide TXOP to > stations (CAPs), and that the overall number of CAPs shouln't not be > over a certain value (0.4 i think). But why such a limited set of > flows result in this error? When there aren't enough CAPs to offer, Are you asking why 0.4 was choosen ? If so, the answer is that it seemed like a decent default. Feel free to change it. > the flows should try to transmit them using regular EDCA contention > rules.... I'm not getting this behavior :( Are you saying that traffics which are not accepted by the scheduler should be accepted anyway and fed into EDCA slots ? This sounds completely broken or maybe I don't understand what you are suggesting. thanks for your feedback, Mathieu
