How to trace the 802.11 channel busy time?

[Alvin SW]

Hi All,

I want to get some measurement about channel usage level on 802.11
network. One way that I am thinking of is by recording the PHY channel
busy time for every nodes for the duration of simulation, and finding
the average. Is it possible to do that in ns3?

Regards,

Alvin

[Alvin SW]

I know that there is a method IsStateIdle() in WifiPhy class, but what
is the best way if I want to actually measure the total time of Idle
state in WifiPhy?

[Alvin SW]

That's look complicated. Is there any other way to do that? I just
want to record the total channel IDLE/BUSY (Not CCA_BUSY) period for
every node in one simulation run.

On Apr 1, 9:44 am, Quincy <quincy....@gmail.com> wrote:
> There is the TraceSource WifiPhyStateHelper::State which you can
> connect a Callback function to. It will notify you of all (except for
> one case) state changes in the Phy. However, the state changes are not
> necessarily notified at the time it occurs. The current implementation
> only notify you of any CCA_BUSY->IDLE transitions when the subsequent
> IDLE->(new state) occurs. Therefore you will also not be notified of
> the final CCA_BUSY->IDLE transition (if exists), and you will need to
> track that yourself through other callback functions.

[Bruno Ranieri]

I am also interested in this topic. My thoughts so far:

In YansWifiPhy::SendPacket the transmissions duration is calculated and
WifiPhy::NotifyTxBegin is called.

WifiPhy::NotifyTxBegin and WifiPhy::NotifyTxEnd are connected to the two
TraceSources PhyTxBegin and PhyTxEnd. WifiPhy::NotifyTxEnd is not called
anywhere.

If one schedules WifiPhy::NotifyTxEnd to Now + transmission duration,
one should get the transmission duration of every transmitted frame.

Is it possible that a transmission is canceled in the YansWifiPhy
context? How do one needs to extend the given TraceSources to trace the
exact timestamps, or how should one do this using the trace system?

regards,
Bruno

Alvin SW schrieb:

[Quincy]

On Apr 1, 11:33 am, Alvin SW <a...@nuansa.org> wrote:
> That's look complicated. Is there any other way to do that? I just
> want to record the total channel IDLE/BUSY (Not CCA_BUSY) period for
> every node in one simulation run.

What do you mean by BUSY? The channel could be "busy" (transmitting,
receiving or blocked) around node A but not node B if they are far
enough apart. It does not make sense to have a global "BUSY" state for
all nodes.

[Quincy]

> In YansWifiPhy::SendPacket the transmissions duration is calculated and
> WifiPhy::NotifyTxBegin is called.

But you can't just add up all the durations from NotfyTxBegin from all
nodes - some nodes may be able to transmit concurrently.

> WifiPhy::NotifyTxBegin and WifiPhy::NotifyTxEnd are connected to the two
> TraceSources PhyTxBegin and PhyTxEnd. WifiPhy::NotifyTxEnd is not called
> anywhere.
>
> If one schedules WifiPhy::NotifyTxEnd to Now + transmission duration,
> one should get the transmission duration of every transmitted frame.

You don't actually need it - you are given the duration in
NotifyTxBegin. The model in NS3 doesn't seem to allow the TX state to
be interrupted.

> Is it possible that a transmission is canceled in the YansWifiPhy
> context? How do one needs to extend the given TraceSources to trace the
> exact timestamps, or how should one do this using the trace system?

To me, it doesn't make sense to be able to cancel a transmission. In
the conceptual TCP/IP or OSI mdoel, Link Layer (MAC) controls whether
and when a transmission occurs, PHY should just do the encoding. Once
a packet passed through MAC, it should already be on the medium (there
may be some delay due to buffering, etc), but you shouldn't be able to
cancel it.

[Quincy]

If you are just after whether a node (the PHY, not the channel) is
IDLE or not, then you can still use the WifiPhyStateHelper::State
TraceSource. Just add up all time the PHY is in IDLE state. the not
IDLE time should just be the global simulation time - the idle time
(assuming you start counting the time at time = 0 and the TraceSource
is attached already). Note that you may still have problems with the
final CCA_BUSY->IDLE transition (you won't know about the last
instance the PHY goes to IDLE).

[Alvin SW]

Hi Quincy,

What I mean by channel BUSY is the state of PHY in a node, which
includes the AIFS and backoff periods, not only CCA_BUSY.
As exactly of what you describe in your last email.
The problem is, I don't know how to code your explanation. Is there
any tutorial about that? Or, would you mind to show some snippets,
especially which arguments to use or method to call to actually get
the duration of the IDLE state.
However, if the final CCA_BUSY->IDLE transition can not be tracked,
then the result from this approach would be inaccurate? Is there
anyway to get around this problem?

Alvin

[Quincy]

There is the TraceSource WifiPhyStateHelper::State which you can
connect a Callback function to. It will notify you of all (except for
one case) state changes in the Phy. However, the state changes are not
necessarily notified at the time it occurs. The current implementation
only notify you of any CCA_BUSY->IDLE transitions when the subsequent
IDLE->(new state) occurs. Therefore you will also not be notified of
the final CCA_BUSY->IDLE transition (if exists), and you will need to
track that yourself through other callback functions.