[Ns-developers] Ns-3 Wsn GSoc 2012

sahil sharma sharmasahil0913 at gmail.com
Fri Mar 30 00:43:25 PDT 2012


Hi,

I will shortly put my proposal. Sorry for the delay, I had certain
per-commitments.

Before I finalize down the things, I want to ask you if I can only add one
approach to
the problem or I can suggest more than one, which further we can finalize
or put
as a backup option.

Another solution that I am thinking about is introducing a new state in
radio:
"WifiState: Dead" which would model the partial-dead state that we have
discussed in the above thread i.e. once a node goes to this state, it can
transmit/receive packets, system will drop its all packets and make way
for the packets that are scheduled for the time when it will be
re-energized
so that it remains synchronized with the system clock and its initial
decided
schedule.

Please Comment.

On Sun, Mar 25, 2012 at 10:20 AM, Tommaso Pecorella <tpecorella at mac.com>wrote:

> 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 resou*rces* 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