Mike's suggestion to read RFC 3561 - Ad hoc On-Demand Distance Vector (AODV) Routing should do the trick; in the meantime, I will go ahead and summarize it for you.
Wireless (routing) protocols, such as AODV protocols, use sequence numbers in a different way than wireline protocols do. AODV maintains a table of destination IP addresses, along with the last sequence number. This way, if it receives the same routing sequence number in an update, it detects the duplicate and drops the update; thus, avoiding a potential loop. Additionally, AODV does not forward/process update packets that it has seen before. The sending node (based on whatever message they send Route request, Route Reply), maintains their own sequence numbers and increments it before sending a new packet out.
AODV is hardly alone in depending upon sequence numbers to avoid loops; RFC 4728 - Dynamic Source Routing (DSR) also depends on sequence numbers. Yet another wireless (multicast) routing protocol that uses sequence number to avoid looping is IETF Draft - The Adaptive Demand-Driven Multicast Routing Protocol for Mobile Ad Hoc Networks (ADMR).
We should note that layer-2 in wireless networks (typically) do not use Spanning Tree Protocol (STP) for loop prevention.
Case of RREP: When nodes receive RREQ (Route request) for a destination node, then two types of nodes can respond to it. One is the destination node itself -- in this case, it can increase the seqeunce ID. The second types of nodes are those that have an existing route to the destination node. Now, they have already saved the seq number that was generated by the destination node, when they received the route. When sending a RREP, these intermediate nodes simply copy the earlier learnt sequence number (and do not generate a new one). This way, if the destination were to send a new route, then the node that generated RREQ, when it receives the RREP, it can pick the one with the latest sequence number and ignore the ones that are stale.
Here is what the RFC says about the destination node sending RREP:
If the generating node is the destination itself, it MUST increment its own sequence number by one if the sequence number in the RREQ packet is equal to that incremented value.
Case of RREQ: Nodes also maintain reverse routes (let us say, for node X) and they would want to update the route to originator of RREQ (node X) only when they receive a new RREQ from node X. One way to do this is to let X increment the sequence number whenever it sends a RREQ.
A note on destination sequence number field in the RREQ: As per section 5.1, when originating RREQ: "Destination Sequence Number: The latest sequence number received in the past by the originator for any route towards the destination.". As per section 6.5, when processing RREQ: "Lastly, the Destination Sequene number for the requested dest is set to the maximum of the corresponding value received in the RREQ message, and the destination sequence value currently maintained by the node for the requested destination."
So, basically, settting/updating Dest Seq Number means that the sender or forwarder of RREQ is indicating that I have the information till, let us say seq 101, that was sent by the destination node. If that is not the latest, then the destination node does not bother to increase its own sequence number before sending the RREP (section 6.6.1).
Best Answer
According to my understanding, they are two different entities. They are completely independent of each other. A node's sequence number gets incremented either when it broadcasts a RREQ packet or when it is the destination node, before sending the RREP packet.