fdojurado / sdwsn-controller Goto Github PK

This will enable the execution of the RL algorithm through the SDWSN

Before running the desired routing algorithm, we need to check if the graph is connected or not. This prevents the routing algorithm to fail.

NC should run in a thread and wait until every packet is acknowledged.

The serial interface should not interfere with other processes and, receive and send packets are done using the queue of this multiprocessing.

This permits to compute the checksum of routes and see if the controller has the same routes. This minimises the control overhead see paper "Energy-aware routing for software-defined multihop wireless sensor networks".

This DB is populated when the NC routing packets have been acknowledged.

Updated: We now populate the NC routing for each node when generating routes and we set the configure flag when they are acknowledged.

There are issues when plotting the currently deployed paths, as some of them stay on the table.

One solution could be to store currently deployed routes in a different DB collection. But, we may need to keep the known sensor routes as well (different collection).

To solve this, we use the latest entry of the "historical-routes" collection, which holds the latest routing paths. We then verify whether these routes have been already deployed or not by querying the "fwd_table".

We want to facilitate the visualization of the network graph by adding the cost for each edge.

When sending the serial data to the controller there is an issue with the byte order. Now it is working correctly with python running in MacBook Pro (14-inch, 2021). It may stop working if it runs in a different architecture.

Check whether the current routing paths have changed. This is needed to decide to send NC packets or not.

We need to create two queues to handle NC packets:

• #18
• #19

We need to have a network visualization to easily visualize the network connection.

Sending and receiving the address python interpret this as a two-byte long and this is not always true for address with x.x

The controller advertises the current schedules to all nodes in the network in a broadcast message.

Broadcast makes more sense as the controller tells all the sensor nodes the schedules for the incoming period.

The routing plot should now only plot deployed routes.

The routing should be executed at a given time and it should run in independent multiprocessing.

This issue will implement a simple routing algorithm in the serial controller. This will require the implementation of all methods needed. In the end, the controller will successfully modify the forwarding paths of all sensor nodes.

• Dijkstra algorithm
• #11
• #1

The current routing table for the entire network should be updated regularly when:

• New routes are computed
• NC routing ACK has been received

The up-to-date routing paths for the network should be stored in a pandas dataframe. This may facilitate the access and processing of such information. This may be done in a separate file containing the class.

The flag should be passed through the terminal command. The flag should be "m".

This is to avoid overflowing the sensor nodes routing table and keep in sync both controller and nodes forwarding table.

Once the paths are found running the routing algorithm, they need to be stored in the correct format in the dataframe. It then needs to be saved in MongoDB.

Suppose we received the following path "1-2-3-4". The following routes are built.

| src | dst | via |
| 1 | 3 | 2 |
| 1 | 4 | 2 |
| 2 | 4 | 3 |
| 4 | 1 | 3 |
| 4 | 2 | 3 |
| 3 | 1 | 2 |

Once we send routing reconfig packets, we need to store the ACKs for that packet, as multiple packets can be sent and ACKs may arrive in a different order.

The controller receives instruction on the specific routing protocol to run from an MQTT client.

The controller should run the MQTT server as an independent process.

This is needed to avoid sending duplicate routes.

Currently, we are saving the routes found using the routing algorithm in the historical-routes db, and we assume that previous routes in db have been already deployed.

However, this might not be always the case. We potentially need to use a flag to identify which routes have been deployed. This flag inherits the status from the historical routes.

One solution is to check if the routes already exist in the node. See issue #16

The NC receives jobs through a Queue.

The submitting user should read the status of the NC, before sending new jobs as it might be finishing a job.

The controller needs to set the hop limit to RA/SA packets. This is a controller BC, so it won't flood the entire network if only requires updating nodes close to the controller.

Currently, neighbours (NBs) are stored within the "Nodes" collection. This is historical data that contains link status with NBs. The routing protocol should have easy and fast access to the current alive links. It does not care for the past link status, at this stage. The historical data can be used for ML implementations in future.

All NC packets are placed in a queue. In this case, we address routing reconfiguration packets. For these packets, we send them in order-therefore they are stored in a FIFO queue.

The Queue should point to the node number instead of the whole data frame.

This is in charge of implementing management functions to run the forwarding table of the entire network.

The user should easily decide on which network (cooja, IoT lab) to connect from the command line.

The controller, which runs natively using python, needs to send network configuration packets to all sensor nodes. Therefore, the network reconfiguration methods need to be implemented.

The controller needs to parse and process schedule report messages