In my opinion, I would suggest treating RSU nodes as their own collection, separate from the OBU nodes. This may give you some advantages, since those two classes or nodes may be different. For example, you correctly note that RSUs are static. There may be several other configuration-related items that you may want to assign to all nodes of the same type. For example: RSU-nodes may use a different (higher) transmit power. They may need to have a "height" (say, 10m), depending on the propagation loss model you assume. They may support additional or different protocols. They may "do something very different" every time they receive a BSM from an OBU (like, send it off on the backhaul). They might handle channel switching differently than the OBU-nodes. RSUs may be directly connected to the internet, or some other network that OBUs cannot consistently connect to. Thus, if you collect all of the RSUs into one set that is separate from the OBU nodes, then it is easier to "set up" the entire collection of nodes all at once. As far as the "fixed position" of the RSUs themselves, you may consider hard-coding that within your script, or you can use the technique similar to the positions of the OBU (cars) - that is, you can (manually) create a separate ns2-style positions-playback file that you associate with your RSU nodes. In that case, then your playback file might have only the initial positions of the RSUs, and then would NOT have any movement items within its playback file.
In summary, collect all the RSU nodes into one node-set, and leave the OBU-nodes in a different node-set. You will still be able to access all-nodes that is the union of them both., but having separate node-sets gives you some flexibility that I suspect you will appreciate later.
I have often wanted to see someone extend the vehicle-only script to also incorporate static RSUs. Thank you for considering this important work.