Applicable Versions
NetSim StandardNetSim Pro


Applicable Releases
v12v13


New nodes can be added anytime during simulation by modifying the source codes. One way of achieving this behavior is to set the radio state of the devices which you want to introduce in the simulation at a later point of time, to OFF state at simulation start. At a later point in time, its radio state can be reset to IDLE to make it alive. These nodes will not be part of the DODAG structure initially.


Nodes that are to be added to the network after a specific time, need to be part of the original network scenario designed in the GUI.  They can be 'introduced' into the network after a specific time via code changes.


Consider the following network scenario:


Let us consider that we want to introduce sensor 1 into the network after 10 seconds.

Follow the steps to introduce nodes into the network after a specific period:

1. Open NetSim Source codes by going to Your Work  (Open Simulation in v12)-> Workspace Options and clicking on the Open Code button. 
2. In the 802_15_4.c file go to the fn_NetSim_Zigbee_Init() function and add calls to the function fn_NetSim_Zigbee_ChangeRadioState(), which has the following prototype:

fn_NetSim_Zigbee_ChangeRadioState(NETSIM_ID nDeviceId, PHY_TX_STATUS nOldState, PHY_TX_STATUS nNewState);

For Eg:

_declspec (dllexport) int fn_NetSim_Zigbee_Init(struct stru_NetSim_Network *NETWORK_Formal,\
NetSim_EVENTDETAILS *pstruEventDetails_Formal,char *pszAppPath_Formal,\
char *pszWritePath_Formal,int nVersion_Type,void **fnPointer)
{
pstruEventDetails=pstruEventDetails_Formal;
NETWORK=NETWORK_Formal;
pszAppPath =pszAppPath_Formal;
pszIOPath = pszWritePath_Formal;
fn_NetSim_Zigbee_Init_F(NETWORK_Formal,pstruEventDetails_Formal,pszAppPath_Formal,\
pszWritePath_Formal,nVersion_Type,fnPointer);
fn_NetSim_Zigbee_ChangeRadioState(1, WSN_PHY(1)->nRadioState, RX_OFF);
return 0;
}

This means that the node with ID 1 will be in an OFF state right from simulation start and hence will not take part in the DODAG formation or any other communication. It is as if Node 1 is not there.

3.. You can later change the device state using a similar call to fn_NetSim_Zigbee_ChangeRadioState() function based on certain conditions to turn it on (set its state to IDLE):

For Eg:
You can add a condition in the fn_NetSim_Zigbee_Run() function to turn ON node with ID 1 after 10 seconds, as shown below:
       
_declspec(dllexport) int fn_NetSim_Zigbee_Run()
{
SUB_EVENT nSub_Event_Type;
NETSIM_ID nDeviceId, nInterfaceId;
nEventType=pstruEventDetails->nEventType; /* Get the EventType from Event details */
nSub_Event_Type=pstruEventDetails->nSubEventType; /* Get the sub EventType from Event details*/
nDeviceId = pstruEventDetails->nDeviceId;
nInterfaceId = pstruEventDetails->nInterfaceId;
if (pstruEventDetails->dEventTime > 10 * SECOND && WSN_PHY(1)->nRadioState == RX_OFF)
 fn_NetSim_Zigbee_ChangeRadioState(1, WSN_PHY(1)->nRadioState, RX_ON_IDLE);
/*Check event type*/
switch(nEventType)
{

This means that the node of device id 1, will be turned ON after 10 seconds of simulation if it was previously in OFF state. 

4. ZigBee project has to be rebuilt before running simulations for the code changes to have an impact on further simulations performed.


Results and Analysis:


Upon running the simulation with the above code changes, we can observe the impact in the RPL log file and the packet trace log file as shown below:



From the packet trace log file shown above, we can see that node 1 after getting turned ON after 10 seconds broadcast a DIS message, to request information from nearby DODAG. 




In the RPL log file shown above, we can see that Node 1 starts becoming active after 10 seconds and further chooses Node 2 as its parent, and Node 3 becomes its sibling.


Related articles:

is-rpl-protocol-available-in-netsim-

how-to-view-a-node-s-rank-parent-and-sibling-in-rpl-based-iot-simulations-

how-ranks-are-distributed-in-rpl-implemented-on-netsim-