Can't change the default value for ns3::LbtAccessManager::Txop while running laa-wifi-indoor.cc

[Jonghun Park]

Hi, 

I'm trying to run 'laa-wifi-indoor.cc' example with a short Txop period, saying 160 millisecond, for some reasons.

Could anyone help me to set it correctly? My best try couldn't reach to the right way. 

To change both Txop value and its range to be checked, I modified related (global and default) variables in the example files, 

and then I am facing a SIGABORT from the line setting the default value;

Config::SetDefault ("ns3::LbtAccessManager::Txop", TimeValue (MicroSeconds (lbtTxop*1000))). 

And the error message is  

---

msg="Could not set default value for ns3::LbtAccessManager::Txop", file=../src/core/model/config.cc, line=682

terminate called without an active exception

Program received signal SIGABRT, Aborted.

---

by debugging, I found out in Config::SetDefaultFailSafe() that the attribute value wasn't set properly. 

---

701  for (uint32_t j = 0; j < tid.GetAttributeN (); j++)

(gdb)

703      struct TypeId::AttributeInformation tmp = tid.GetAttribute(j);

(gdb)

704      if (tmp.name == paramName)

(gdb)

706          Ptr<AttributeValue> v = tmp.checker->CreateValidValue (value);

(gdb) n

707          if (v == 0)

(gdb) p v

$6 = {m_ptr = 0x0}

(gdb) p value

$7 = (const ns3::AttributeValue &) @0x7fffffffd730: {<ns3::SimpleRefCount<ns3::AttributeValue, ns3::empty, ns3::DefaultDeleter<ns3::AttributeValue> >> = {<ns3::empty> = {<No data fields>}, m_count = 1}, _vptr.AttributeValue = 0x615330 <vtable for ns3::TimeValue+16>}

(gdb) p tmp

$8 = {name = "Txop", help = "Duration of channel access grant.", flags = 7, originalInitialValue = {m_ptr = 0x719690}, initialValue = {

   m_ptr = 0x719690}, accessor = {m_ptr = 0x718cd0}, checker = {m_ptr = 0x718c40}}

(gdb) bt

#0  ns3::Config::SetDefaultFailSafe (fullName="ns3::LbtAccessManager::Txop", value=...) at ../src/core/model/config.cc:707

#1  0x00007fffefefa072 in ns3::Config::SetDefault (name="ns3::LbtAccessManager::Txop", value=...) at ../src/core/model/config.cc:680

#2  0x0000000000406699 in main (argc=2, argv=0x7fffffffdc88) at ../scratch/laa-wifi-indoor.cc:339

(gdb) n

709              return false;

(gdb)

---

In the further debugging, I encountered one weired operation in Time class; 

Although g_markingTimes is a null pointer, the program went into the if-clause in line 202, as you can see in the following debugging log.  

----

(gdb) n

339      Config::SetDefault ("ns3::LbtAccessManager::Txop", TimeValue (MicroSeconds (lbtTxop*1000)));

(gdb) s

ns3::MicroSeconds (value=160) at ./ns3/nstime.h:877

877  return Time::FromInteger (value, Time::US);

(gdb) s

ns3::Time::FromInteger (value=160, unit=ns3::Time::US) at ./ns3/nstime.h:406

406    struct Information *info = PeekInformation (unit);

(gdb) n

407    if (info->fromMul)

(gdb)

409        value *= info->factor;

(gdb)

415    return Time (value);

(gdb) s

ns3::Time::Time (this=0x7fffffffcda0, v=160000) at ./ns3/nstime.h:200

200    : m_data (v)

(gdb) list

195      {

196 Mark (this);

197      }

198  }

199  explicit inline Time (unsigned long int v)

200    : m_data (v)

201  {

202    if (g_markingTimes)

203      {

204 Mark (this);

(gdb) n

202    if (g_markingTimes)

(gdb) n

204 Mark (this);

(gdb) p g_markingTimes

$1 = (ns3::Time::MarkedTimes *) 0x0

(gdb) s

ns3::Time::Mark (time=0x7fffffffcda0) at ../src/core/model/time.cc:282

282  CriticalSection critical (GetMarkingMutex ());

(gdb) bt

#0  ns3::Time::Mark (time=0x7fffffffcda0) at ../src/core/model/time.cc:282

#1  0x000000000040fd21 in ns3::Time::Time (this=0x7fffffffcda0, v=160000) at ./ns3/nstime.h:204

#2  0x000000000040fdf9 in ns3::Time::FromInteger (value=160000, unit=ns3::Time::US) at ./ns3/nstime.h:415

#3  0x000000000040fff3 in ns3::MicroSeconds (value=160) at ./ns3/nstime.h:877

#4  0x000000000040663d in main (argc=2, argv=0x7fffffffdc88) at ../scratch/laa-wifi-indoor.cc:339

---

My best understanding so far is that this marking procedure caused to set the attribute value for Txop improperly, but I am not sure. 

Thank you for your time and consideration in advance. 

- John

[Yu-chan Hsu]

Hello,

If you want to tune the Txop of lbt, you can add the parameter "--lbtTxop=8" to your command line, like what is shown below.

./waf --run “laa-wifi-indoor --lbtTxop=8”

Or you can find all configurations by typing the line

./waf --run “laa-wifi-indoor --PrintGlobals”

Yu Chan

[Jonghun Park]

Sorry for confusing! I was trying to change it to 160 MICROSECONDS which is much shorter than the default minimum Txop in the example, so that I have to change the default setting.

[Yu-chan Hsu]

Sorry for my misconception.

I try to modify the file (/src/laa-wifi-coexistence/lbt-access-manager.cc) line: 170 and run successfully, but the answer is not verified yet.

170.      MakeTimeChecker (MilliSeconds (4), MilliSeconds (20)))  modify to  MakeTimeChecker (MilliSeconds (0.1), MilliSeconds (20)))

I guess the function: MakeTimeChecker checking if the value between the minimun(0.1) and maximum value(20) or not, 

so that the value 160 MICROSECONDS => lbtTxop = 0.16 will work.

Yu Chan

[pdbarnes]

Caution: Time constructors smaller than Seconds() only take integer arguments. Instead of MilliSeconds(0.16) you need MicroSeconds(160).

Peter

[Yu-chan Hsu]

Thanks for Peter's helpful comments!

The right way should substitute function MicroSeconds() for MilliSeconds().

[Jonghun Park]

For whom this might be a concern, 

FYI, 

As Peter mentioned below, the thing which made me hard to test very short txop(<1ms), although it's not feasible for a practical system for some reason, is the set of time scale conversion functions defined in the Time() class that uses uinteger types in some routine.

So, the shortest txop I applied so far is 1ms. 

On Wednesday, April 13, 2016 at 12:45:00 AM UTC-5, Jonghun Park wrote:

[Barnes, Peter D.]

Hello Jonghun,

I finally got a chance to look at the code.  In the public repo [1], ns3::LbtAccessManager::Txop is limited to the range 4-20 ms.[2]  Perhaps that’s an issue you’re encountering?

Peter

[1]  http://code.nsnam.org/laa/ns-3-lbt
[2]  http://code.nsnam.org/laa/ns-3-lbt/file/056f37aea269/src/laa-wifi-coexistence/model/lbt-access-manager.cc#l170

On Apr 23, 2016, at 8:11 AM, Jonghun Park <johnjhp...@gmail.com> wrote:

As Peter mentioned below, the thing which made me hard to test very short txop(<1ms), although it's not feasible for a practical system for some reason, is the set of time scale conversion functions defined in the Time() class that uses uinteger types in some routine.

So, the shortest txop I applied so far is 1ms.

_____________________________________________________________
Dr. Peter D. Barnes, Jr. NACS Division
Lawrence Livermore National Laboratory Physical and Life Sciences
7000 East Avenue, L-50 email:  pdba...@llnl.gov
P. O. Box 808 Voice:  (925) 422-3384
Livermore, California 94550 Fax:    (925) 423-3371

[Jonghun Park]

Hi Peter,

Exactly. the range, 4 - 20 ms, is just limited by the checker's. 

I could change it to any integer valued min,max pair. 

What I want to is to set the value around 100 micro second. 

So, I tried to change the time units of LbtTxop to microsecond by using MicroSecond() function, but I didn't get any luck to find the codes which change the varible to zero.

Even if I put '160' in the example code after all related routines(I think) in microsecond scale, the debugger showed me that the value become nulled to zero.

Hope this is helpful for your try. 

Thank you so much for your time and consideration, Peter!

best, 

- Jonghun

[lorenza....@gmail.com]

Hi Jonghun,

I am not sure I got your question, but by definition, the Txop is the maximum number of subframes during which LTE can transmit continuously. The time granularity of LTE in general and of the simulator in particular is the subframe, i.e. 1 msec, so for LTE it would

Not be possible to transmit during only 100 us. This value is not feasible. There are not data transmission that may happen at this granularity in LTE.

Hope this helps,

Lorenza

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Jonghun Park]

Hi Lorenza, 

Thank you so much for the reply. I totally agree with your point on the granularity, as I mentioned in one of previous replies. 

I came up with this extreme case when I wanted to give a laa base station a similar airtime with one packet transmission time of 802.11n configured with very high data rate, like 72.2Mbps or higher, for my research.

Since specifiation says like that, I understand that the current version of simulator might not run with such small value. 

I thought, at the begining of this questioning, it would be possible with some modification. 

- Jonghun

[lorenza....@gmail.com]

Hi Jonghun,

You cannot go below this granularity to send data in LTE module. Also consider that in 3GPP the minimum value for txop has been set to 8 ms, and in LTE-U Forum specs LTE can transmit in uninterrupted fashion during 20 msec. In addition there is a minimum allowed time for continuous transmissions of 4 msec. So those are the kinds of values we should see in real products soon.

Hope this helps,

Lorenza