As lookingforajob has said there can be many reasons for track jitter - jumping is a little more difficult to achieve but I have seen it.
The first is a Kalman filter issue where as LFAJ explained the system extrapolates the next position of the aircraft from its previous radar track positions it puts a box around that and if the next position is anywhere in the box it recenters the track report in the box if the track was right at the edge though it will increase the size of the next predicted box this repeats and usually if it is track jitter the next report will be close to the predicted position. If the aircraft had started a turn the effect is for the aircraft displayed track to continue in a straight line for 3 or even 4 responses then suddenly the filter accepts it is not jitter and the displayed response jumps to where the actual response was - this can be disconcerting if you instruct an aircraft to turn for deconfliction and it appears to continue on the original heading.
Another track jump problem can be caused with primary returns in a 'mosaiced' radar display system where multiple radars are used. A secondary response will these days normally have mode 3/A and C so a position and an altitude. From this altitude the radar processing can convert the slant range to actual range to the plan position of the aircraft. If there is no altimeter then the processing still has to convert the slant range to actual plan range but now has to 'guess' (cough) use a default parameter. This would normally be something like 25,000 ft for an en-route radar. Now imagine that your mosaic has a PSR served area next to an SSR served area the PSR is using the default 25,000ft the SSR is using the actual 38,000ft it is actually possible to have two returns for the same aircraft in cases like this as the PSR thinks the aircraft is in its mosaic area and the SSR knows the aircraft is in its area. An intermittent altimeter squawk can also create two aircraft.
A final way to have problems is if the comms system from the radars to the control center is having problems and a simple buffering on overflow is happening. This can result in some PSR positions getting through on time and others sitting in a buffer. The controller sees intermittent position reports for the aircraft then the buffer releases the data being held and the controller suddenly gets old primary responses and the aircraft appears to jump back a few miles then the next response gets through and the aircraft jumps forward several miles and so on. Add in tools that use the last responses of the aircraft to 'predict its vector' usually a simple line ahead of the aircraft with a length equating to say a minute's flight - and now you have a recipe for confusion as the aircraft dances back and forth along its track the prediction similarly points back then forward with unrealistic projections of where the aircraft will be.
I would think that it is the last of the three that is the problem. I saw it sometime ago on a NATS system when the digitisers at the radar heads were being swamped by weather. However, Tehran doesn't seem to have that kind of weather so I would go for a ground datalink comms problem causing buffering of the radar returns from the radar head so they are being received by the processors in the control center in a semi-random sequence.