If you are not changing the table on which you have open cursor (are you sure you are not making DML on it through triggers or procedures?), then someone else must have changed some rows while your cursor was opened on it.

In all circumstances, ORA-1555 is caused because the database can't construct read consistent view of the data in a table as of the moment when you opened the cursor.

Here is a possible scenario:

1. In time T1 you opene the cursor on table TABLE1
2. In time T2 transaction TRANS2 change some blocks on TABLE1. The blocks contents before the cahnge (that is, blocks content as it was in time T1) are stored in rollback segment and are protected from being owerwritten. They are not protected because of your cursor's read consistent view, but because transaction TRANS2 might need them in case it need to perform rollback.
3. Until TRANS2 commits your cursor will always get read consistent view of the changed blocks from rollback segment.
4. In time T3 TRANS2 commits. From that moment on the changed blocks in rollback segment are not protected any more, because the transaction which changed them doesn't need them any more. Any other transaction can use this part of rollback segment.
5. In time T4 some other transaction TRANS3 owerwrite those roollback segment's blocks. The original data of the changed blocks from TABLE1 as it was in time T1 no longer exists in the database!
6. In time T5 your cursor tries to fetch next row from TABLE1. If this row is stored in changed blocks, then the sistem can not get the content of this row as it was in the time T1 (even though maybe TRANS2 haven't changed this particular row, it might have changed some other row from this same block that was not even included in a result set of your cursor!). And voila - ORA-1555.

HTH,