SMAC protocol

[apple]

Hi!

Is anybody simulated the SMAC protocol in NS3? Would you like to
communicate with me? Please contact me.
I am going to convert the NS2 SMAC model into NS3. However, it seems
very difficult.

Many thanks!

Best regards,
Ping

[neveratnever1]

HI dear,
  Im doing my project regarding smac in ns3.. Could you please forward me how to do implementation of SMAC in ns-3.. I have installed ns-3.11 on my machine Could you please send me those details of SMAC as soon as possible
waiting for your reply
 
Many thanks..




 

[neveratnever1]

On Friday, November 13, 2009 4:02:30 PM UTC+5:30, apple wrote:

Hi,
 Im new to the ns3. Im trying to implement smac protocol in NS3. I need the code for smac could you please forward me that code and just give me the overview so that i can submit for my course project.

Thanks
naveen.



 

[prasanth]

 have you done implementing S-MAC protocol on ns-3....?

if you have already,can you please send me the code....waiting for your reply...
thank you...

[prasanth]

have you done implementing S-MAC protocol on ns-3....?

if you have already,can you please send me those code....waiting for your reply...

thank you... 

[Tommaso Pecorella]

S-MAC is available here: http://www.isi.edu/ilense/software/smac/index.html

... but it's not for ns-3.

As far as I know, there's no S-MAC implementation for ns-3. If anybody wants to do it, feel free to use the recent lr-wpan module and extend it with S-MAC.

If anyone wants to do that, make sure to contact the lr-wpan developers, they'll be more than happy to assist you on starting up the task.

Cheers,

T.

[Michael Nishimura]

Bumping a long-dead post here, but I have an interest. I'm working on implementing a protocol based on S-MAC, and wonder if, for parallel simulation purposes (that is, simulation on a cluster), I'd be better off trying to implement S-MAC for ns-3, since it has built-in MPI support, or taking an existing implementation of S-MAC (for ns-2, Avrora or TOSSIM) and extend those simulators to be parallel. (via MPI or similar)

I feel like reimplementing S-MAC would put me in a better position to extend the protocol, but hear it's very challenging to do so. I also am pretty new to the concept of wsn's, and don't have much of an idea about the technical challenges involved, which makes it difficult to estimate the amount of effort involved. It looks like the ns-3 community is much more active than the TOSSIM community, and Avrora looks completely dead, which is a consideration in favor of extending ns-3.

I have about 800 hours (5 months full time) before leaving this project to someone else with more experience with WSN's, and I'd rather make a good start at it in that time. 

If someone (particularly the lr-wpan developers, since they seem to have an interest and are probably the most knowledgeable on the subject) could provide a comparative effort estimate or advice on how I should proceed, that would be wonderful.

[pdbarnes]

Well, since S-MAC is for wireless channels, and ns-3 doesn't support parallelization of shared channels, I wouldn't tackle a port hoping to get parallel execution. (Of course the infrastructure portions of a scenario can be parallelized, but you get no parallelism within individual shared channels.)

However they are still many other good reasons to port to ns-3.

Peter

[Michael Nishimura]

Let's see if I get the terminology. Thank you very much for the response, by the way. Corrections of my interpretations here would also be appreciated.

In a many-member wireless network on a common bandwidth, we consider ourselves to have a single "wireless channel". Different networks may communicate on different channels/bandwidths, which may or may not interfere, depending on how close they are (I suspect our simulation will be single-channel by nature of S-MAC). Ns-3 simulates such a wireless channel in a single thread, or possibly multiple threads on a node (but DEFINITELY NOT as threads on a cluster. Single or shared memory is a requirement of the implementation. Actually, whether its multi or single threaded is possibly important). It IS, however, possible to simulate infrastructure (i.e. Wireless nodes, specifically the sensors S-MAC is for) in parallel.

So now my question about suitability of ns-3 changes to "estimate the computational gains of parallelizing infrastructure as part of a ns-3 wireless network simulation using the S-MAC protocol". I'm not looking for massively parallel processing, just a few nodes and a few dozen processors, a decent length of simulation time, that hopefully takes less than a month to run. So, do you have any idea about how much processing simulating a shared channel is, relative to simulating its nodes? I assume the answer depends on how much traffic the nodes generate, and how detailed their simulation is, so for what levels of traffic and simulation fidelity might I expect to see a processing bottleneck? (Keeping in mind S-MAC is the power-conserving protocol it is)

This seems like a tough question to answer. Hopefully the criteria I've given narrow it down enough for an answer. I'll try to get an estimate about orders of magnitude of fidelity, number of nodes, and projected traffic tomorrow.

I barely understand what I'm talking about, so correction of any major misconceptions would be great. Also, I'm a CS student, so my original question about porting difficulty stands. I've checked over the original S-MAC source for NS-2, and it seems pretty self-contained, apart from a couple calls to the energy model, but I have little idea of what's implemented in NS-3 in those departments, nor any idea of how that fits into the broader simulation context. Hopefully over the next while I'll get a slightly better handle on the scope of my task.

[Peter Barnes]

On Mar 12, 2015, at 7:18 PM, Michael Nishimura <arbit...@gmail.com> wrote:

In a many-member wireless network on a common bandwidth, we consider ourselves to have a single "wireless channel". Different networks may communicate on different channels/bandwidths, which may or may not interfere, depending on how close they are (I suspect our simulation will be single-channel by nature of S-MAC). Ns-3 simulates such a wireless channel in a single thread, or possibly multiple threads on a node (but DEFINITELY NOT as threads on a cluster. Single or shared memory is a requirement of the implementation. Actually, whether its multi or single threaded is possibly important). It IS, however, possible to simulate infrastructure (i.e. Wireless nodes, specifically the sensors S-MAC is for) in parallel.

That's half right. Wireless models in ns-3 using SpectrumPhy can model interference. Unfortunately the 802.11 model is NOT one those, so it's challenging and only approximate to model interference in WiFi. 

The key requirement for parallelization is not shared memory per se, but Look Ahead, or a non-zero ower bound on the latency between nodes on the channel. Since wireless nodes can be arbitrarily close together the lower bound is zero latency, so they can't be parallelized (not with any efficiency). Even threading (experimental) only gives modest speed up (x2). 

My use of the word "infrastructure" was unfortunate. What I meant was nodes connected by point-to-point links (and 2-node CSMA, which can be replaced with equivalent throughput P2P links). To run a scenario in parallel you have to find regions connected to the rest of the topology solely by P2P links. Each such region is eligible to run on a separate MPI rank in the parallel execution. How you map regions to the available MPI ranks us up to you. 

As for execution performance, in topologies with just P2P and CSMA we measure ~10k packet receptions per compute node per wall clock second. (See our paper in SimuTools 2013 and upcoming in WNS3 2015. Our benchmark model has minimal routing overhead, OnOff traffic, and no (or extremely few) collisions. I expect wireless, routing, etc to take more cycles, but AFAIK no one has published a benchmark model and measured it. YMMV, professional coders, closed cluster. Do try this at home.)

Peter

[Tommaso Pecorella]

Hi Michael,

I can't say if it's best ns-3 or the other alternatives. Obviously I'd say ns-3, but I'm quite biased :)

Anyway, let's try to have a fair comparison.

- AVRORA: limited to AVR microcontrollers. I wouldn't suggest it.

- ns2: limited 802.15.4 models. Too limited compared to the ns-3 ones.

- TOSSIM: limited to the TinyOS operating system. The good part is that you can flash it on a mote right away. The bad part is that it's TinyOS.

To be fair, I'd add also...

- Cooja: same limitations as TOSSIM, but it's made for ContikiOS

- RiOT: I'd strongly suggest this one, but it's not a simulator. You can use it on a dummy target (i.e., run it on your PC), but it will not use an emulated 802.15.4 as far as I know.

- ns-3: I'm very biased about ns-3... otherwise I wouldn't be here.

And now let's discuss about one thing in particular: the idea to run it on a cluster. Let's say straight away... forget about it.

Motivations... the channel.

You can separate in different threads a simulation, but for wireless systems you'll have one limitation: the channel. That's a common object, and all the threads need to use the same channel for interference and propagation. Shortly put, the channel is the bottleneck.

Actually the MPI ns-3 features are made by isolating different "clusters" of nodes that can run in parallel because they're (mostly) independent. There's a special channel to let the cluster communicate: the Remote point-to-point links. For a more complete discussion see https://www.nsnam.org/docs/models/html/distributed.html

If you plan to use MPI or WSN simulations, you'll have to work on that part as well. Otherwise you'll be able to simulate different PAN clusters, ut only if they don't interfere each other. I.e., different (and non-overlapping) channels and/or spatially distributed PANs.

About the time effort, I'd concentrate on either the MPI for wireless problem or on the S-MAC implementation. In 5 months you should be able to complete the S-MAC for ns-3. It's not that dramatic :)

The MPI for wireless problem is outside of my competence. I can't evaluate its feasibility or the technical difficulty.

However, there's one thing you may consider in order to speedup the simulations.

I've been able to simulate in near-real time a group of "some" nodes (1000) in a multihop scenario. You could profile the simulation and see where it may be optimized. A hint is: the spectrum model is computationally intensive. Perhaps moving the calcs in the GPU could provide "some" performance bonus ?

PS: this message wasn't posted yesterday due to an error, so Peter's replies weren't considered. I agree with him, and I think that the most important part would be to profile your code. Again, the bottleneck should be the spectrum channel model.

[Michael Nishimura]

So basically, I can parallelize for designed topologies, specifically by isolating clusters of nodes by area? That sounds... exactly applicable to a LR-WPAN using S-MAC over a fairly widespread area, because those are extremely low-interference by design. Definitely not a solution for general wireless communications, but should be pretty usable in this special case.

So, a different question. How much effort is it to convert a ns-3 simulated protocol into wsn hardware? TinyOS has the advantage of being easy to flash to motes. It looks like most motes, I'd need to convert to C based on the wikipedia page list of wireless sensor nodes. C++ to C typically isn't terrible, depending on how many C++ features you use, I think.Or we can be restricted in mote options, I suppose.

That is another 4 month project in and of itself, of course, I'd expect not much less. But does it sound feasible given that timeframe?

[Tommaso Pecorella]

On Friday, March 13, 2015 at 2:36:40 PM UTC+1, Michael Nishimura wrote:

So basically, I can parallelize for designed topologies, specifically by isolating clusters of nodes by area? That sounds... exactly applicable to a LR-WPAN using S-MAC over a fairly widespread area, because those are extremely low-interference by design. Definitely not a solution for general wireless communications, but should be pretty usable in this special case.

Indeed. I don't know what's the point of simulating non-interfering clusters tho. Your project, your decision.

  

So, a different question. How much effort is it to convert a ns-3 simulated protocol into wsn hardware? TinyOS has the advantage of being easy to flash to motes. It looks like most motes, I'd need to convert to C based on the wikipedia page list of wireless sensor nodes. C++ to C typically isn't terrible, depending on how many C++ features you use, I think.Or we can be restricted in mote options, I suppose.

Suggestion: don't even think to it.

TinyOS is written in NesC, a horribly cumbersome C dialect. It shares the C instructions, but that's it.

Contiki is Embedded C (a slightly more standard C than NesC), but it's simply a nightmare. Just consider that global variables used in totally different code points are normal.

RiOT is the most "normal", and after NesC and Embedded C, it seems almost like programming a normal thing. However, its hardware requirements are a bit more stringent.

My suggestion is: first decide the hardware and OS. Do a joint decision, otherwise you'll find yourself trapped in a deadly loop.

After you have your hardware / software settled, study the algorithm with ns-3 (easier debug, no memory constraints, etc.), then you'llbe able to implement a reduced complexity thing in the hardware you have.

 

That is another 4 month project in and of itself, of course, I'd expect not much less. But does it sound feasible given that timeframe?

Sounds feasible, if you already have a good experience on the target OS. If you don't, I'd avoid TinyOS and Contiki: you'd need 1 month just to understand how they work.

Of course, this is my opinion. Mileage may vary.

Cheers,

T.

[Michael Nishimura]

I'll have to start a discussion about hardware selection. Thanks for the advice.

As to why we're simulating mostly non-interfering clusters, let me first see if I understand why you think that's pointless. Is it just an incredible simplification of the entire simulation, such that it makes using a simulator at all overkill, and I'd be better off using some other tool with regards to performance/ease of porting/converting to sensor behavior?

We're just trying to use a fairly simple spread WSN with the focus being on periodic (but permanent) node failure. We expect nodes to degrade over time and eventually fail, and utilize their degradation rates to make estimates about the intensity of the degrading effect (I like the phrase "ablative detection"). Our focus is very much not on the effects of interference or collisions; in fact, we picked our protocol to minimize such effects. Our primary concern in simulation is simulation performance, followed by translatability, followed by fidelity, since we plan on studying the degrading effects with actual nodes; the simulation is more to suss out protocol suitability/necessary modifications, edge cases, and to demonstrate proof of concept. If you have suggestions for a better way to capture those, I'd love to hear it. (no sarcasm, it would be very helpful). While our particular simulation case would probably be better off ignoring interference/collisions, I believe the S-MAC protocol is designed with collisions considered, so hopefully a port will be applicable to other cases.

Thank you so much for your help. It is greatly appreciated, and I hope I can make an at least somewhat useful contribution to your project as part of my work.

[Tommaso Pecorella]

Hi,

well, it's an open discussion, so take my point of view as it is: a point of view.

Separate clusters are pointless (in my opinion) because they'll not give you more info than one cluster.

They'll sense different things (otherwise they'd be spatially overlapped) and they'll not send infos to each other (better, probably they don't). I assume they all send data to a common server.

As a consequence, more cluster are good "only" to evaluate the effect of massive sensing over the common part: the server.

However, the very same analysis can be carried out by studying a single cluster, extracting the traffic patterns, and make a 2nd simulation with only a few nodes generating the aggregate traffic. It would be faster in this way.

Having different clusters will make your simulation more complex and, probably, harder to analyze.

KISS: Keep It Simple (and Stupid).

If the clusters can be overlapped... well, that would change everything. Some points in the overlapping case are:

1) the "clusters" are different PANs on different (non-interfering) channels ?

2) Why they're on different PANs ?

3) The sensing events are correlated ? E.g., you have a PAN for temperature and one for seismic events.

Anyway, I'd still study one PAN as a start.

Node failure... interesting topic, but you forgot one little thing... the routing :/ It's a multihop WSN, right ? Then you need routing, and that's even more important than the MAC. I'd say way more critical for the network resilience.

Simulation performance > translability > fidelity...

It depends on what's your goal. If you want to do a rough estimation with the simulator, and then move to a real testbed, then I agree that fidelity is the last point. However, you need some degree of fidelity. Otherwise your simulation could point you in the wrong direction.

I'd put the prios in this order: decent fidelity > performance > total fidelity > translability.

Translability is the very last thing you want, otherwise you should really consider Cooja or TOSSIM. The point is: a simulator goal (usually) isn't to be a rapid prototyping tool. You can, of course, check algorithms and write code in a way that leads to a minimal overhead translation, but NOT for WSN. WSN operating systems are so tiny, so limited and so specialized, that translating code is more difficult than to rewrite it. Otherwise you'll end up by using bad code in both cases.

One possibility to overcome this limitation is to use DCE (Direct Code Execution), but as far as I know DCE can't yet run Contiki or RiOT. Plus, as I said before... you should choose your OS because you want it, not because you're forced to use it by the simulator.

Summarizing, I'd not bother with translability. The simulator goal is to provide insights on the algorithm you develop, and to give you indications on what to do and what to NOT do. Once you know what's going on, the pitfalls and how to avoid them... rewriting code for the target platform is easy.

Cheers,

T.

[Anurag Patro]

hello guys,
I am trying to implement SMAC protocol using NS2 but it has some errors as I am beginner to  NS2 please anyone give me code for SMAC in NS2

[Konstantinos]

Hi Anurag,

this is the NS-3 mailing list. NS-3 is a different simulator from NS-3.

Please send your questions to the NS-2 list.

[Tommaso Pecorella]

Hi,

SMAC is not available for ns-3 (yet), but it would be a very welcome addition. Since in the last GSoC Vishwesh Rege extended the actual 802.15.4 code to support multiple MAC implementation (he did implement ContikiMAC), it should be easier now to add also SMAC to the existing modules.

Summarizing, if you're going to implement SMAC my suggestion is to evaluate if you need to use ns2 or ns-3. In case you'll choose ns-3, we'll be more than happy to give you support.

For ns2... sorry, but we're not prepared.

Cheers,

T.

[Ritwik Jain]

Hi,Ping

    You can give me the code of smac protocol in ns2  simulator.and how i can run the code please also give me the guideline.

    Ritwik Jain