How to wakeup sensor nodes in wsn using ns2? - sensors

i am new to ns2,i want to simulate routing protocol in wireless sensor networks,anyone tell me how to wake up sensor nodes by transferring sink node wakeup message and how to get node position?

Hello read Leach protocol in ns-2
you will learn how the nodes are sleep and awake.

Related

Query related to AF_XDP for transmission of data

I'm developing a user space application where my end goal is to send data from a Linux machine A (an embedded device) and receive on another Linux machine B (an embedded device) over AF_XDP. I want to use AF_XDP to achieve low latency.
I understand for my user space application to receive data over AF_XDP I should use XDP_REDIRECT (please correct me if I'm wrong), what I can't understand is which XDP option (XDP_REDIRECT, XDP_TX etc) should I use to transmit data from my user space application over AF_XDP?
what I can't understand is which XDP option (XDP_REDIRECT, XDP_TX etc) should I use to transmit data from my user space application over AF_XDP?
That is not how AF_XDP works. Once all of the setup work is done, by you or a library you use, there will be a shared memory region called UMEM and 4 ringbuffers which are used in a sort of dance to receive and transmit packets. The buffers are called: UMEM_Fill, UMEM_Completion, RX, TX
On the ingress side, your XDP program is triggered so you can make a decision to send traffic to your AF_XDP socket or not. Here you will use the bpf_redirect_map to redirect the traffic into the socket/map which will return XDP_REDIRECT if successful (may fail if the socket isn't setup correctly or buffers are full).
To read the redirected packet you dequeue the RX queue/ring, the frame descriptor within will point to an address in UMEM which is where your packet data is located. As soon as you are done with this memory you send the frame descriptor back over the UMEM_Fill queue/ring so the NIC/Driver can re-use it.
To write a packet you dequeue a frame descriptor from the UMEM_Completion queue/ring fill the region of UMEM you have temporary control over with your packet and give the frame descriptor to the TX queue/ring. The NIC/Driver will consume the TX queue/ring and send out the packet. No XDP program is triggered on egress.
Would highly recommend you checkout https://www.kernel.org/doc/html/latest/networking/af_xdp.html which has more details regarding using AF_XDP.

Broadcasting a data packet in a wireless sensor network

I have created a network of 100 sensor nodes using python 3.8. Now I need to broadcast a node's information like it's energy, id etc to other nodes and all the other nodes should listen to the information. So, how can I implement this in python?

How to stay connected to a Bluetooth LE bathroom scales in Linux

I just got a Bluetooth LE/Smart bathroom scales (Model Sanitas SBF 70). I can read data from it using the following command:
gatttool --device=(btaddr) -I
connect
Then when I stand on it, I get multiple notification messages like this:
"Notification handle = 0x002e value: e7 58 01 05 e9"
where the last two bytes are is the mass in 50g increments.
I'd like to integrate this into a few application using a TCP or UDP socket service that broadcasts these messages to any listening clients.
But after some research I have no idea what's the best way to stay connected all the time (the connection times out after a few minutes). Or alternatively to be able to re-establish a connection when the scales is used (I notice lots of activity from 'hcitool lescan' whenever someone steps on the scales).
I don't care what language / library is used. If I can push this to a TCP/UDP socket it will be trivial for other applications to consume the information.
The answer is straightforward: You don't.
Your scale is most likely battery powered. Therefore the Bluetooth communications will only be enabled for a short period of time after having measured your weight. Your application just needs to try connecting to the scale over and over (catch any "unable to connect timeouts") until you step on it. And when connected get the data from it before BLE is shut down again. In pseudo code:
while true:
while not_connected:
try to connect
receive notifications
disconnect
gatttool wrapped by the python module pygatt is perfectly usable to solve this chalenge.
In my case scale data (preceding 30 weights) is transferred after enabling indications of 3 different characteristics.

BLE connection interval

From BT snoop log below, found BLE central device and peripheral device got connected after a few loops of negotiation about
connection parameters, include connection interval, connection latency and supervisor timeout etc.
As found in bt snoop log, the connection interval will be set to 1 second, my question is:
Why not found the connection between them disappear 1 second later after they connected?
What’s the real meaning of connection interval?
As you know BLE has a pillar that is to be low energy consumption.
The main rule is turn on the radio as little as possible and turn off the radio as soon as possibile.
When a connection is established the radio signal isn't always active even when a peer want to transmit. The transmission phase has the radio turns on and off more times.
The connection interval is the time between two connection event and inside each connection event there is packets transmission.
Suppose the peer wants to transmitt 10 packets : the radio signal is on for packets transmission (max 6 packets) then turned off for a time that is the connection interval ... now 6 packets are transmitted. After connection interval, the radio is turned on to transmit tha last 4 packets and so on.
The connection interval can be from 7.5 ms and 4 s and it depends on both peers.
Of course, lesser connection interval means high baud rate transmission but more power consumption and vice versa.
Paolo.
BLE is a radio communication protocol that work in the 2.4GHz spectrum.
If you measure the radio current on a CRO, while it is in a connection, you will get a graph something similar to shown above.
The peaks indicate that radio is turned ON. Between the peaks the device is sleeping to save power.
To put it simply, connection interval is the time interval between the peaks.
Meaning it is the time for which the device sleeps after sending a packet and then wakes up to send a packet again.
This timing is synchronized between the two communication devices. It is like two people agreeing to meet at a particular time and place.

Object push to bluetooth without pairing

Is it possible to send some notification messages to the nearby Bluetooth devices without pairing.I have found some protocol for these - OBEX Oject Push. But am not clear whether is is feasible without pairing request .Any demo apps for reference?
Yes and no.
If you are actually talking about connecting but not pairing, then, yes.
If you are talking about no connection at all, then no.
When creating a Bluetooth connection between two or more devices the following steps are taken.
Inquiry – If two Bluetooth devices know absolutely nothing about each other, one must run an inquiry to try to discover the other. One device sends out the inquiry request, and any device listening for such a request will respond with its address, and possibly its name and other information. The closest located device is not necessarily the fastest to respond and any device that hears the call will try to respond.
Paging – Paging is the process of forming a connection between two Bluetooth devices. Before this connection can be initiated, each device needs to know the address of the other (found in the inquiry process).
Connection – After a device has completed the paging process, it enters the connection state. While connected, a device can either be actively participating or it can be put into a low power sleep mode.
• Active Mode – This is the regular connected mode, where the device is actively transmitting or receiving data.
• Sniff Mode – This is a power-saving mode, where the device is less active. It’ll sleep and only listen for transmissions at a set interval (e.g. every 100ms).
• Hold Mode – Hold mode is a temporary, power-saving mode where a device sleeps for a defined period and then returns back to active mode when that interval has passed. The master can command a slave device to hold.
• Park Mode – Park is the deepest of sleep modes. A master can command a slave to “park”, and that slave will become inactive until the master tells it to wake back up.
Two devices can be bonded together through a one-time process called pairing. When two devices are paired, they store each other’s addresses, names and profiles in memory, allowing them to automatically establish a connection as soon as they are in range of each other.
It is not possible to send OPP (or other) communication between two devices before connecting.
It is possible to send communication between two devices after connection but before pairing.

Resources