Open In App

Distributed Priority Scheduling

Last Updated : 06 Jan, 2023
Improve
Improve
Like Article
Like
Save
Share
Report

Distributed Priority Scheduling is a technique that piggybacks the priority tag of a node’s head of Line packet onto handshake and data packets. By monitoring transmitted packets each node maintains a scheduling table into existing 802.11. The scheduling table is an estimate of its relative priority in medium access control.

Contention-Based Protocols with Scheduling Mechanisms

Distributed priority scheduling and medium access in Ad Hoc Networks present two mechanisms for providing quality of service(QoS).

  • Distributed priority scheduling (DPS): It piggybacks the priority tag of a node’s current and head-of-line packets of the control and data packets.
  • Multi-hop coordination: It extends the DPS scheme to carry out scheduling over multi-hop paths.
Piggy-backing and scheduling table update mechanism in DPS

 

RTS- Ready To Send
CTS- Clear To Send
NAV- Neighbor Allocation Vector
ACK- Acknowledge

Process of DPS

  • Suppose, Node 1 and Node 2 wants to communicate with each other i.e, node 1 wants to send data to node 2. The shaded part(piggyback) of RTS in node 1 stores the priority information/tag. In this case, we take it as 9. That RTS is sent to the RTS of Node-2. RTS of node-2 will read that priority.
  • The packets run on a priority basis. Now, according to priority, the destination source decides whether it wants to send CTS or not. If it thinks that 9 is valid for further processing, then it will send CTS. The same information will be sent to the CTS of node-1 back.
  • The neighbor node i.e, Node-4 updates itself when node-1 and node-2 are communicating without interrupting them. When at the start it hears the RTS package i.e, 9, at that time, the initial state of node-4 is ST(a). It has a table of Source, Destination, and Priority which is known as the Scheduling Table. So, he finds out from its table that Source is 1, Destination is 2 and Priority is 9 and updates itself as the ongoing transaction. NAV did not stop until the communication between node-1 and node-2 stopped.
  • Back to two communication nodes, when it got CTS, it will send its data. Now, node-2 has its data. Node-1 is free now. So, suppose now this node wants to send data to node-6, it will create a head-of-line. This means that which is the next packet to send. Then again the neighbor node will work the same it will update itself with source, destination, and priority in its table in ST(c).
  • Now, when node-2 will send its ACK back, the transaction in ST(c) will be deleted. Deleting the current transaction, it goes back to its initial state. In this way, the whole process works.

Basically in DPS, it requests to send then get back as a reply clear to send, then data is received and lastly, it gets acknowledged.


Like Article
Suggest improvement
Previous
Next
Share your thoughts in the comments

Similar Reads