Skip to first unread message
william
Dec 6, 2016, 12:23:02 PM12/6/16
to ns-3-users
In some simulations I've been running, NotifyMaybeCcaBusyStartNow seems to be behaving in a way that doesn't make much sense to me. This is some output from simulation where 4 clients (Clients 1, 2, 4, and 5) have chosen the same number of initial slots to start their backoff, so they all attempt to send at the same time. It makes sense that they all report their own Tx starts but I have an issue with the CCA Busy calls.
You can see that the DcfManager's for each client get 3 different calls to NotifyMaybeCcaBusyStartNow at almost exactly the same time (so, one for each other client that's sending at that same time). According to the documentation - CCA Busy: the PHY is not in TX or RX state but the measured energy is higher than the energy detection threshold. This makes sense, but it doesn't seem realistic that these DcfManager's should be able to receive 3 of these calls at the same time, or to know that the PHY layer is "Busy" three different times. Is this a bug, or how are the PHY layers able to determine that it's measuring above the energy detection threshold multiple times, as it seems this should only be done once.
0.00123626s [DcaTxop-Dequeue] (Client 5) Type:MGT_ASSOCIATION_REQUEST PckSize:34 SeqNum:0 Uid:1
0.00123626s [DcaTxop-Send MacLow] (Client 5) Type:MGT_ASSOCIATION_REQUEST Retry:0 PcktSize:34 SeqNum:0 Uid:1 -- Must wait for ACK;Normal ACK protocol;
0.00123626s Client 5: Tx start for +38000.0ns
0.00123626s [DcaTxop-Dequeue] (Client 4) Type:MGT_ASSOCIATION_REQUEST PckSize:34 SeqNum:0 Uid:2
0.00123626s [DcaTxop-Send MacLow] (Client 4) Type:MGT_ASSOCIATION_REQUEST Retry:0 PcktSize:34 SeqNum:0 Uid:2 -- Must wait for ACK;Normal ACK protocol;
0.00123626s Client 4: Tx start for +38000.0ns
0.00123626s Client 4: Cca busy start for +38000.0ns
0.00123626s Client 3: Rx start for +38000.0ns
0.00123626s Client 5: Cca busy start for +38000.0ns
0.00123626s [DcaTxop-Dequeue] (Client 2) Type:MGT_ASSOCIATION_REQUEST PckSize:34 SeqNum:0 Uid:4
0.00123626s [DcaTxop-Send MacLow] (Client 2) Type:MGT_ASSOCIATION_REQUEST Retry:0 PcktSize:34 SeqNum:0 Uid:4 -- Must wait for ACK;Normal ACK protocol;
0.00123626s Client 2: Tx start for +38000.0ns
0.00123626s Client 3: Cca busy start for +38000.0ns
0.00123626s [DcaTxop-Dequeue] (Client 1) Type:MGT_ASSOCIATION_REQUEST PckSize:34 SeqNum:0 Uid:5
0.00123626s [DcaTxop-LOW] (Client 1) Type:MGT_ASSOCIATION_REQUEST Retry:0 PcktSize:34 SeqNum:0 Uid:5 -- Must wait for ACK;Normal ACK protocol;
0.00123626s Client 1: Tx start for +38000.0ns
0.00123626s Client 2: Cca busy start for +38000.0ns
0.00123627s Client 1: Cca busy start for +38000.0ns
0.00123627s Client 3: Cca busy start for +38000.0ns
0.00123627s Client 2: Cca busy start for +38000.0ns
0.00123627s Client 2: Cca busy start for +38000.0ns
0.00123627s Client 1: Cca busy start for +38000.0ns
0.00123627s Client 4: Cca busy start for +38000.0ns
0.00123627s Client 1: Cca busy start for +38000.0ns
0.00123627s Client 3: Cca busy start for +38000.0ns
0.00123627s Client 5: Cca busy start for +38000.0ns
0.00123628s Client 4: Cca busy start for +38000.0ns
0.00123628s Client 5: Cca busy start for +38000.0ns
You can see that the DcfManager's for each client get 3 different calls to NotifyMaybeCcaBusyStartNow at almost exactly the same time (so, one for each other client that's sending at that same time). According to the documentation - CCA Busy: the PHY is not in TX or RX state but the measured energy is higher than the energy detection threshold. This makes sense, but it doesn't seem realistic that these DcfManager's should be able to receive 3 of these calls at the same time, or to know that the PHY layer is "Busy" three different times. Is this a bug, or how are the PHY layers able to determine that it's measuring above the energy detection threshold multiple times, as it seems this should only be done once.
Reply all
Reply to author
Forward
0 new messages