Since I’ve not personally used PANS I’m not sure but I don’t think it will do what you want.
In your system I’d go with a timeslot by consensus approach.
You don’t have a master to assign timeslots but you know you have a fixed maximum number of nodes, if you don’t mind running at your worst case update rate even if only half the nodes are switched on then you can hard code the timeslots.
You know you have a maximum of 16 nodes. Each node needs to make 15 range measurements. Add a 1 time slot transition period and you end up with 16*16 = 256 time slots.
I’m assuming each node knows it’s ID number.
So Node 1 gets timeslots 1-15, node 2 gets timeslots 17-31 etc…
Each node powers up assuming it’s the timeslot just after it’s transmission time is over and listens to all packets even if they aren’t addresses to them. It it gets a packet it then syncs its internal timeslot count to match the data in the packets it’s seeing. Otherwise it increments the timeslot count at the expected rate.
This way everyone ends up in sync without a master setting the things up. Since when exactly each units timeslot ticks up isn’t in sync you will normally end up running a tiny bit slower than the intended rate but not by much. The one idle slot between units means that you should never end up drifting far enough out of sync to end up on top of each other.
256 timeslots, a two way range can easily be done in 2 ms so you have an update period of 512 ms. Less if you reduce the time taken for the range measurement.