[Ns-developers] Ns-3 Wsn GSoc 2012

sahil sharma sharmasahil0913 at gmail.com
Tue Mar 27 15:22:56 PDT 2012


I was trying one wireless implementation. Basically, I want energy-drain
event to happen for a particular node so that I can implement the further
changes. But getting no such information, only info of packet delivery, may
I need to add/modify LOG and I am not very clear about them or something
else.

Please help. The code is:



#include "ns3/core-module.h"
#include "ns3/point-to-point-module.h"
#include "ns3/network-module.h"
#include "ns3/applications-module.h"
#include "ns3/wifi-module.h"
#include "ns3/mobility-module.h"
#include "ns3/csma-module.h"
#include "ns3/internet-module.h"

using namespace ns3;

int main (int argc, char *argv[])
{
 LogComponentEnable ("UdpEchoClientApplication", LOG_LEVEL_INFO);
  LogComponentEnable ("UdpEchoServerApplication", LOG_LEVEL_INFO);

LogComponentEnable ("WifiRadioEnergyModel", LOG_LEVEL_DEBUG);
LogComponentEnable ("WifiRadioEnergyModel", LOG_LEVEL_INFO);


NodeContainer wifiNodes;
wifiNodes.Create (3);

YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
YansWifiChannelHelper wifiChannel = YansWifiChannelHelper::Default ();
wifiPhy.SetChannel (wifiChannel.Create ());
WifiHelper wifi = WifiHelper::Default ();
NqosWifiMacHelper wifiMac = NqosWifiMacHelper::Default ();
wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager");
wifiMac.SetType("ns3::AdhocWifiMac");
NetDeviceContainer wifiDevices = wifi.Install( wifiPhy, wifiMac, wifiNodes
);

MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (5.0),
"DeltaY", DoubleValue (10.0),
"GridWidth", UintegerValue (3),
"LayoutType", StringValue ("RowFirst"));
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (wifiNodes);

InternetStackHelper internet;
internet.Install (wifiNodes);     Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer wifiInterfaces;
wifiInterfaces = address.Assign( wifiDevices );

UdpEchoServerHelper echoServer (9);
ApplicationContainer serverApps = echoServer.Install (wifiNodes.Get( 0 ));
serverApps.Start (Seconds (1.0));
serverApps.Stop (Seconds (100.0));

UdpEchoClientHelper echoClient (wifiInterfaces.GetAddress (0), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1000000));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (0.0001)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));
ApplicationContainer clientApps = echoClient.Install ( wifiNodes.Get( 2 ) );
clientApps.Start( Seconds (2.0) );
clientApps.Stop( Seconds (100.0) );

Ipv4GlobalRoutingHelper::PopulateRoutingTables ();

Simulator::Stop (Seconds (105.05));
Simulator::Run ();
Simulator::Destroy ();
return 0;
}

On Tue, Mar 27, 2012 at 10:14 AM, Tommaso Pecorella <tpecorella at mac.com>wrote:

> Hi,
>
> time zones = answer delay :P
> Have you checked out the doxygen ?
>
> The links I sent you in a previous mail are doxygen. Usually I jump from
> Doxygen pages to raw code reading. More explicit that those it's
> impossible. Clearer maybe would be possible, but nobody did one (as far as
> I know).
> Btw, all the stuff that you might consider not relevant for the project
> it's really somewhat relevant at the end. You'll "mess up" with inner
> functions that could break everything, so anything learnt is relevant to
> give you the broader picture.
>
> T.
>
>
>
> On 27/mar/2012, at 00:56, sahil sharma wrote:
>
> Hi,
>
>   One last thing for today.
>
>   Which resource *i.e. ns-3 tutorial, documentation OR any-other* I
> should pick up and be focused about to get a better insight of all this to
> mention about the things much clearly on my application. I have read most
> part of the ns-3 tutorial and  as it had many extra details, and few of
> them tangential to the project requirements, it was not a good experience.
>
>   Suggest me some resources wherein I can get clear picture of the object
> structure and all the classes that will be used in our project. I guess,
> documentation is the only way out.
>
>   Any other reading or resources, please suggest?
>
> On Mon, Mar 26, 2012 at 6:16 PM, Tommaso Pecorella <tpecorella at mac.com>wrote:
>
>> Hi,
>>
>> you're getting there I'd say. On the other hand from here on the only way
>> to lift your doubts it's to check with... the code. Go and dig into the
>> code, thy to follow it and see what are the drawbacks and the problems.
>>
>> There are things that can not be planned, and that will be re-planned
>> once you start looking  at the code. What was clear might become obscure,
>> and viceversa. So... go for the code !
>>
>> Start with something simple, like the csma module. There are some
>> examples using it in examples directory, and the module itself is in
>> src/csma.
>>
>> Once you'll see the code you'll have more doubts, or less. More precise
>> anyway :)
>>
>> I can only give you a couple more hints:
>> 1) not every ns-3 class is derived from the Object class. For the ones
>> that aren't derived from it, you'll need a "backup" plan, as you can't
>> change their derivation so easily. Btw, in ns-3 we try to avoid as much as
>> possible multiple inheritance. I'll not start explaining why we do so, but
>> trust me if I say that it's better to stick with it.
>> 2) once you'll see the code you'll learn that:
>> 2a) instances are always synchronized, as the "time" is a global concept
>> in ns-3.
>> 2b) ideally the stop/non stop check result shall be extremely limited,
>> like in one accessor function, so to avoid code like:
>> if (!stopped)
>> {
>> [....] do all your stuff
>> }
>> else
>> {
>> [...] do something different
>> }
>> That would make the code unreadable and un-maintaineable.
>> 3) internal object state is more a bitch than it seems. Just think about
>> TCP: the congestion window shall be reset when you stop a node... little
>> things that makes the difference.
>>
>> Anyway, time to write your application I guess.
>>
>> Good luck with it (it's a contest after all, and I'm only one among many).
>>
>> Cheers,
>>
>> T.
>>
>>
>>
>>
>>
>> On 26 Mar 2012, at 21:57, sahil sharma wrote:
>>
>>
>>
>> On Sun, Mar 25, 2012 at 7:10 PM, Tommaso Pecorella <tpecorella at mac.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> A semaphore could do, but of course a full state is more useful. Same
>>> result tho :)
>>>
>>>    Thats perfect. I am able to visualize a semaphore based solution.
>>
>> This have to do with how a node is aggregating "things".
>>>
>>> Let's make a simple example: a node with a CSMA interface.
>>> http://www.nsnam.org/docs/doxygen/classns3_1_1_node.html
>>> http://www.nsnam.org/docs/doxygen/classns3_1_1_ipv4_l3_protocol.html
>>> http://www.nsnam.org/docs/doxygen/classns3_1_1_csma_net_device.html
>>> http://www.nsnam.org/docs/doxygen/classns3_1_1_csma_channel.html
>>>
>>> They ALL are classes derived from Object.
>>>
>>>    This made me understand things better. So in all, node class,ipv4
>> class,
>>    csma_net_device class and channel class all child classes of object
>>    class. So in order to make changes, add such common variable,
>>    that can be accessed by every object i.e.channel,ipv4 etc.,we will
>> definetly
>>    have to make it to object class.
>>
>>
>>>  To have an example of a scheduled event you have to dig a little
>>> deeper, as usually classes do not use them directly. They do use Timer
>>> objects (Timer object fire a Callback function) or they pass data to the
>>> upper or lower levels. You'll find Events fired in the Applications or in
>>> the Channels usually. An example:
>>>           Simulator::ScheduleWithContext (tmp->GetNode ()->GetId (),
>>> Seconds (0), &ErrorNetDevice::Receive, tmp, p->Copy (), protocol, to, from);
>>> So you want to see this:
>>> http://www.nsnam.org/docs/doxygen/classns3_1_1_simulator.html
>>>
>>> If I'm not wrong the above all is of this kind:
>>>   template<typename MEM , typename OBJ , typename T1 , typename T2 ,
>>> typename T3 , typename T4 , typename T5 >
>>>   static void  ScheduleWithContext (uint32_t context, Time const &time,
>>> MEM mem_ptr, OBJ obj, T1 a1, T2 a2, T3 a3, T4 a4, T5 a5)
>>> as is a template function. The thing you need to notice is:
>>> mem_ptr member method pointer to invoke
>>> obj the object on which to invoke the member method
>>>
>>> so, to make long thing short, an event is sent to a particular instance
>>> of a particular object, e.g., one particular channel holding some pointers
>>> to the objects that will receive the callback fired by the object reception.
>>>
>>> You could as well forget about channel-based events, as they should
>>> trigger a "Receive" function in the corresponding NetDevice, but nothing is
>>> guaranteed 100%. Anyway, not a biggie if you don't cover all the cases.
>>> Moreover one can as well give strict direction about how to write a module
>>> compliant with the start/stop model.
>>>
>>> The things you metioned were not very clear to me. Can you me an example
>>> and
>>>
>>     suggest some good links/resources to get better insight for
>> scheduling classes.
>>     I have good experience with IEEE802.11 MAC protocol. It would be
>> great if you can
>>     send me some link add add on your explanation for scheduling
>> challenges which we
>>     may have to face by implementing this semaphore scheme to it (scheme
>> explained
>>     in detail below).
>>
>>
>> Possible, but let me make another counter-example.
>>> 1st and foremost: a timer fires ONE function, it's responsibility of
>>> that function to re-schedule the timer. So, how do you cover this case:
>>> A node have some packets in the queue to be sent.
>>> It start a channel contention and acquire the grant to send N packets in
>>> the channel.
>>> It send the first one and schedule a timer to send the next one.
>>> Its energy goes off.
>>> When the energy come back, is this "timer" still active ?
>>> Shall it start sending packets out of the blue ?
>>> No.
>>>
>>>    Your argument is very correct. But, as suggested the semapore scheme
>> will work as:
>>    It will have  a semaphore as a variable to top-most object that would
>> be associated
>>    with each-node with values=0 for POWER-OFF and value=1 for POWER-ON.
>> Firstly,
>>    I would like to clarify that node will remain synchronized with system
>> clock even when
>>    in OFF state AND second important thing : As I had previously
>> mentioned that we
>>    can put in (if-else) check to allow execute normal functions i.e.
>> sendout() only when
>>    POWER-ON state, but we will also put in functionality/code for the
>> else part i.e.
>>    if POWER-OFF state, we would not just skip that normal function but
>> drop the packets
>>    that were scheduled at that time-period so that node can resume its
>> functionality as was
>>    decided for it initially (obviously skipping for the energy-drained or
>> rebooting period). This
>>    would save us from re-synchronization and re-arranging things
>> unnecessarily. Thats how,
>>    observing each function at every layer, ie. for every object we can
>> add/append such functionality.
>>    sendout() was just one example.
>>
>>   For your example, yes let node chooses it CW=21 and its energy-gets
>> drained,courses of
>>   events for that node:
>>   1.Set object state to POWER-OFF.
>>   2.Now, when it will finish with CW and would proceed to further sending
>> packet events,
>>      wherein for every function, we will see state is POWER-OFF for the
>> node, we will
>>      DEQUE the packet instead of sending it(as sening would be for
>> POWER-ON state).
>>
>>  So yes, when energy comes back, "timer" will still be active, infact it
>> was never-gone,
>>  to keep node synchronized with rest of system and continue once it gets
>> replenished.
>>
>>  No, out of blue packets, i.e. if node had to send 10 packets at 1,2,3 so
>> on.....10 seconds.
>>  and we have energy loss at 2.1 second and gets replenished and back at
>> 4.7 seconds.
>>  So, node would  definitely drop packet that was scheduled at 3 second
>> and 4 second
>> and they will not be sent to destination and after it gets back, it will
>> start by sending packet
>>  that was scheduled at 5 seconds.
>>
>> See the above counter-example. In that case what you could want to clean
>> up the pending transmission queue, as the packets are lost OR to send them
>> after a new contention period. It should be the module itself to take care
>> of the "right" action.
>>
>> Thus, in the ideal case, there is a Clean State, and a "Semi-Clean"
>> state. What we want is to have the flexibility to be able to define those
>> "semi-clean" states after a restart (if needed), as there is no obvious
>> choice to enforce. The only real choice would be to put the node and all
>> its aggregate objects in the same state as the one at simulation start, so
>> clean queues, reset variables and so on. However it's not flexible.
>> Still, I could as well be happy with that.
>>
>> Last but not least: you could be a little lost now on how a Node "owns"
>> its devices and such. A naive answer is: they're added through
>> "AddApplication" and "AddNetDevice", but you'd be surprised to know that
>> you shall NOT think about it in this way.
>> Instead, look at the Object class:
>> http://www.nsnam.org/docs/doxygen/classns3_1_1_object.html
>> and in particular to:
>>
>> http://www.nsnam.org/docs/doxygen/classns3_1_1_object_1_1_aggregate_iterator.html
>>
>> An Object (thus a Node) can "Aggregate" other Object, and that's the glue
>> between all the elements composing a node. They're all aggregated to the
>> same object (technically, they're all aggregated), so from ANY
>> Object-derived class instance you can ask for ANY other aggregated instance
>> of some kind in the same object.
>> You're in the middle of a UdpL4 function and you want the pointer to the
>> Icmpv6 layer of your own node ?
>> Ptr< T >  GetObject (TypeId tid) const
>> and the problem is solved (not to be used frequently, it's quite slow).
>>
>> Anyway, as you see there are a lot of inner points to make it work, but
>> basically the semaphore idea is not totally wrong. What I wanted to point
>> out is... it's not THAT simple, there's a lot of things that need to be
>> taken care of.
>>
>>
>> Suggest me some good links on how to proceed further to get a better
>> insight of things,
>> wherein I can actually see working of all things leaving the
>> non-important ones.
>>
>>
>> Cheers,
>>
>> Sahil
>>
>>
>>
>>
>>
>> On Sun, Mar 25, 2012 at 5:05 PM, Tommaso Pecorella <tpecorella at mac.com>wrote:
>>
>>> Hi,
>>>
>>> sorry, I forgot to mention. Nodes can NOT be de-instantiated (aka,
>>> released from memory). This is a ns-3 design constraint.
>>>
>>>
>>> About the
>>>
>>> On 25 Mar 2012, at 22:48, sahil sharma wrote:
>>>
>>> Hi,
>>>
>>>    I have a little doubt.
>>>
>>>    As an ideal situation, The Node Off for rebooting or EnergyDepleted
>>> can be
>>>    implemented by cancelling all the events scheduled and removing each
>>> Node's
>>>    NetDevice from channels, may be even other few other i.e. as must be
>>> done
>>>    when simulations get over.
>>>
>>>
>>> There is no obvious way to remove events from the scheduler once fired.
>>> I which there was one, but there isn't. The problem is more complex than it
>>> seems, as events are not "for the node", are for a specific object that
>>> belongs to the node.
>>> The events happened when the node (object) is "off" shall be dropped
>>> (i.e., shall not fire any other event). It might be responsibility of the
>>> object itself to take care of this.
>>>
>>> Also, there is no obvious way to "detach" a network interface from its
>>> channel. There is no guarantee that there is a channel even. It's logical
>>> to have one, but it's not mandatory !
>>>
>>>    Can't we make things simpler by not draining these useful information
>>> (i.e.
>>>    event scheduler, which can be used if node is rebooted/re-energized
>>> and
>>>    if Node needs to continue with the previously assigned schedule)  or
>>> by not
>>>    doing an extra effort for any such removal or de-installation for
>>> drained node.
>>>
>>>
>>> What you're describing is a "frozen" node, as is one that retains its
>>> status while in off period. The hidden issue with this is about the object
>>> timers. Who's going to reschedule the events for the object itself ?
>>> Let me make an example: your PC is scheduled to do something every 10
>>> seconds. You put it in sleep mode 3 seconds before the timer expiration.
>>> When you wake it up again, the event will happen after 3 seconds ? I'm not
>>> sure about it, but the event SHALL fire sooner or later. Now, who's going
>>> to take care of this ?
>>>
>>> If you want a friendly suggestion, don't even try to consider this case.
>>> Organizing a clean reboot is more than enough to drive you mad, you don't
>>> want to add more headaches sources.
>>>
>>>     Given an assurance that depleted/rebooting node won't
>>> interfere/participate
>>>     in any simulator event, while or till it is in its dead/non-ready
>>> state.
>>>
>>>
>>> That's a perfectly stopped node, and I'd be happy to reach this point.
>>>
>>>     I want to know if it would be enough to give such virtual impression
>>> of rebooting
>>>     or we will have to remove the NetDevice and start up with a all
>>> new-node as we
>>>     need to do at the start?
>>>
>>>
>>> As I said, you can't remove the Object, so you have no choices.
>>>
>>> Cheers,
>>>
>>> T.
>>>
>>>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>     --------------------------------------------------------------
>>>
>>> $25: for you a pizza and some beers with friends, for someone
>>>      might change their lives. Think about it.
>>>
>>> Kiva.org - Loans That Change Lives
>>>
>>> --------------------------------------------------------------
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>> --------------------------------------------------------------
>>>
>>> Thinking evolution:
>>>  "To be is to do" - Socrates
>>>  "To do is to be" - Sartre
>>>  "Do Be Do Be Do" - Sinatra
>>>  "Scooby Dooby Do" - Scooby Do
>>>  "Yaba Daba Doo!" - Fred Flintstone
>>>
>>> --------------------------------------------------------------
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>
>>     --------------------------------------------------------------
>>
>> $25: for you a pizza and some beers with friends, for someone
>>      might change their lives. Think about it.
>>
>> Kiva.org - Loans That Change Lives
>>
>> --------------------------------------------------------------
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>
> --------------------------------------------------------------
>
> Thinking evolution:
>  "To be is to do" - Socrates
>  "To do is to be" - Sartre
>  "Do Be Do Be Do" - Sinatra
>  "Scooby Dooby Do" - Scooby Do
>  "Yaba Daba Doo!" - Fred Flintstone
>
> --------------------------------------------------------------
>
> 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