[Ns-developers] Ns-3 Wsn GSoc 2012

sahil sharma sharmasahil0913 at gmail.com
Fri Mar 30 00:55:42 PDT 2012


Hi,
>
>    Sorry for the previous mail. It had certain errors.
   Apology!

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:
> Once a node is enegy-drained or is re-booting, we change its state to

   "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 *
> cannot*
> transmit/receive packets, system will drop its all packets.
>


> OR in other words we would do the reworking in code for every module

   so as to implement the working of this DeadState and ensure the instance
   of an object remains isolated for energy-drained period but still it
remains
   synchronized with existing system and doesn't drain its complete
information
   which can be used once it gets re-energized.

   Reworking would be done for Phy, wifi NetDevice, IPv4, TCP/UDP and other
   modules, if required.

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