[Ns-developers] Ns-3 Wsn GSoc 2012

Tommaso Pecorella tpecorella at mac.com
Sun Mar 25 07:20:11 PDT 2012


Hi,

you mention two orthogonal points.

One is how to effectively start and stop an object, the other one is what to take into account when considering an energy drain. Usually (but not always) the energy drained by a node is mainly due to the radio part, so it was modeled first. Nothing prevents to define new energy depletion models based, for example, on the CPU cycles, however those are quite hard to estimate, as they do depend on the CPU architecture, the compiler, the code and so on.

In order to have a manageable GSOC project, I'd limit it to the already difficult start and stop problem.

Even limiting yourself to this point, there are a number of things to be taken into account.
1) you can easily start a node (at simulation start), and you can trick them to stop. However the "restart" function is all but obvious, as it involves a refresh of the object internal states to a "clean" state. Now, Objects do NOT have such a functionality right now. The should *remember* their initial status maybe ? I don't know, it's part of your approach. However one could leverage the knowledge that goes back to ancient latin, if you can get the hint.

Another pitfall that must be avoided is *where* to put the required functionalities. The topic has been discussed in the past among ns-3 developers and there was a general consensus that the only logical place where to put such a functionality (Start(), Stop() and so on) is the very base "Object" class (Tom and Mathieu can correct me if I'm wrong). Now, playing with the Object class is all but easy, however it will have the pro to have an automatic chain reaction on all the ns-3 elements... almost. So one shall also check if there are classes NOT derived from Object that need to be considered.

So, summarizing, the main problem here is not really how to take into account the energy depletion or regeneration (that's easy). The problem is what to do when the energy is depleted.

Once you'll have a clear view of the way, adding another function like "poke me when the residual energy is below 5%" should be almost trivial.

If you need a talk, feel free to send me a mail.

Cheers,

T.


On 25 Mar 2012, at 14:44, sahil sharma wrote:

> HI, 
>   Can we add another interface for cpu-device-energy-model on the parallel lines as we have for radio-device-energy model as part of this START/STOP project by adding another model to container and different states to that model i.e. for various processing  protocols which switches their processing according to energy left in energy-source.  I was thinking if we can implement this by adding (getTotalCurrent()=getCurrentA + getCurrentB) where [getCurrentB] is the energy for various modes in this new processing models. 
> 
>    Even  I was thinking if we can add some constant increasing energy function to the energy-source being implemented where ns3 users can define their own increasing function based on which energy will keep on increasing so as to support vast area of energy scavenging protocols.
> 
>    Can you please help me refine these ideas?
> 
>    Can this be added as part of this project for this summer?
> 
>    Apart from this can you give me an insight so as to how I can get idea of supporting REBOOT in this model[as suggested on your ideas page] and where i can get more idea about this as I was thinking that we can support such rebooting by introducing this energy-increasing model. [as suggested above for energy-scavenging protocols where we can attach some constant energy supplying source i.e. solar to the node]
> 
>    Sorry for being too long. 
> 
> 
> 
> On Fri, Mar 23, 2012 at 5:10 PM, sahil sharma <sharmasahil0913 at gmail.com> wrote:
> Hi,
>   I got through various resources and documentation for the energy model being implemented in ns3 for node stop/start project.
> 
>   From what seems to me, overall we have facility for "Energy source objects" and "Energy model objects" where former is generator/ initializer , notifier, energy calculator of various energy related events and latter being consumer that uses this energy generated by energy source object.The Energy Source base class keeps a list of devices . When energy is completely drained in Energy Source base class, the Energy Source will notify all devices that uses its energy. Each device can then handle this event independently, based on the desired behavior when power supply is drained.
> 
>   There were few issues with the above scheme, first and foremost being:
> 
> 1.No provision for stopping the nodes even after Energy source has passed EnergyDrained message to all the devices[as in Gsoc   ideas list] : I read a few solutions for them i.e. taking depleted node and isolate it completely from the current system OR 
> losing the contact between above layers and physical layers to not let it receive or send further messages.
> 
> To me, though both of them might fix the problem temporarily but they doesn't seem to be a generalized solution to the above posed challenge as nodes would still be active i.e application layer still sending packets to lower layers and thus making things unreal [node with nill energy still generating messages, best unrealistic thing one can ever achieve]
> 
> Though i am still researching more about it and how the things have been fixed up by other simulators, but i have few solutions that can be implemented to fix this thing:
>  
>  (A)   Early stoppage for the node: EnergyDrain message being passed to the devices can also be passed from the source to 
>           application layer for abnormal termination[i.e. resetting end time] and thus not allowing it to send any messages further.      
>           Thus, we can create blockage to messages at the uppermost layer itself. I hope, it won't create any undesired cross     
>           inter-dependence between the layers.
> 
>  (B)   Extending network lifetime: Network lifetime considered as depletion of first node, we can provide scheme such that if   
>          battery level of node goes below a certain threshold, we can remove particular node's support completely from relaying,
>          thus saving energy for early depleting nodes.
> 
> I have other ideas like giving a support through parallel continuous energy supplying source[that should be effective with existing energy source model which gives initial fixed energy] to support research work done in Energy scavenging. And one thing that i found really lacking was not considering CPU usage as the energy consumption thing where now in world of multimedia, this factor is power hungry too. If implemented, we can support energy aware processing and security mechanisms easily in  NS3.
> 
> Though, few of these suggestions may sound unrealistic or inefficient to be implemented, but i am trying to get in as much details as possible to implement the suitable changes in a better way.
> 
> Any suggestions OR the idea that you feel can be better than this ?
> 
> Sahil Sharma
> 
> 
> 
> 
> 
> On Wed, Mar 21, 2012 at 5:29 PM, Tommaso Pecorella <tpecorella at mac.com> wrote:
> Hi,
> 
> I'd like to give you a lengthy answer, but I'm leaving tomorrow morning for the WNS3 workshop, so I'll need to be short.
> 
> Me and Vedran Miletic already did some thinking about the way to do it, and we had some ideas. On the other hand, I don't want to limit your creativity (it's part of GSOC to be propose your approach, we're here to guide you, not to tell you "do this, do that"). 
> 
> Anyway, the target is, as said in the proposal, to increase the flexibility of the Energy Model and the way the various ns-3 models can interact with it in order to achieve the desired functionality. As a hint, I can tell that what me and Vedran was thinking to **seems** to be both elegant, simple and effective. On the other hand, we don't know if it could work as intended. Hence, don't take my words as the Fermat's Last Theorem (i.e., stated and not explained). We could be wrong (or not) and we'll discuss about our ideas in due time.
> 
> Cheers,
> 
> Tommaso
> 
> 
> On 21 Mar 2012, at 22:01, sahil sharma wrote:
> 
>> Hi,
>>  First of all, I would like to congratulate whole  ns-3 team for being selected in Gsoc2012.
>> 
>>  I would like to work for this start-stop project to modify the energy model being included in the existing ns-3. Energy being an important factor esp. for nodes placed in hostile environment where battery replenishing is not trivial makes energy model to implement suggested changes so that this can be implemented for real-time scenarios.
>> 
>>  I am currently going on through various developments that have been already done into this and it seems to be very interesting to me. I am currently reading about the existing energy model being implemented in ns-3 and thinking for the best possible improvements we can make in order to accomplish our desired functionality.
>> 
>>  Can you suggest me some other good resources to gain more expertise in this?
>> 
>> On Sun, Mar 18, 2012 at 5:22 PM, Lalith Suresh <suresh.lalith at gmail.com> wrote:
>> Hi,
>> 
>> On Sun, Mar 18, 2012 at 11:54 AM, Tommaso Pecorella <tpecorella at mac.com> wrote:
>> [snip]
>> >
>> > I don't know if we can add a new GSOC project idea, or how much we can fine-tune one, but I'd be happy to bend the start/stop one so to include specifically this point.
>> >
>> 
>> Just to clarify, the ideas listed on the ideas page are not binding.
>> Proposals that the students come up with needn't be from the Ideas
>> page either. So feel free to add any new ideas to the page or edit
>> existing ones.
>> 
>> 
>> --
>> Lalith Suresh
>> www.lalith.in
>> 
> 
> --------------------------------------------------------------
> 
> The nice thing about standards is that there are so many to choose from.
> And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.
> -- A. Tanenbaum, "Introduction to Computer Networks"
> 
> --------------------------------------------------------------
> 
> Tommaso Pecorella - Ph.D.
> 
> Assistant professor
> Dpt. Elettronica e Telecomunicazioni
> Università di Firenze
> 
> CNIT - Università di Firenze Unit
> 
> via di S. Marta 3
> 50139, Firenze
> ITALY
> 
> email: tommaso.pecorella at unifi.it
>        tommaso.pecorella at cnit.it
> 
> phone : +39-055-4796412
> mobile: +39-320-4379803
> fax   : +39-055-494569
> 
> 
> 
> 
> 
> 
> 

--------------------------------------------------------------

The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569








More information about the Ns-developers mailing list