Large RF robot network
A friend of mine asked me to help with thinking about a solution ...

and that solution is the subject of Petri nets.
I guess your main concern expressed in the question is not how to manage the semi-autonomous units (SAUS), but to identify them. Therefore, my mentioning Petri nets is of low value to this question, but would be of overall high value to your friend.
Unique ID database algorithm
You should already be aware that disbursing unique IDs is a frequent but non-trivial concern in normal information systems function.
In a multi-process environment. It requires locking the increment counter each time a new ID is requested and registered, if you are using an off-the-shelf database management system. If you are writing your own algorithm, you would need to lock-down the code block that performs the disbursement of unique IDs into a synchronized atomic block of code, to allow only one process to execute it at any one time.
Hard-wired vs soft-coded -IDs

You could hard-wire its ID into each unit and then manually register it into the database. And you have to track the increment. But you would still need to inform the hub that a unit is coming online, and assigning a SAU to a hub.

You could hard-wire each unit with an unique ID, and then the hub would assign the hard-id a soft-id.


Why reinvent the wheel?
There is already off-the-shelf embedded/controller boards that does all these and many much more. They are called

Linux micro-computers like the infamous raspberry-pi
IEEE 802.11
IEEE 802.11 hubs and routers
Internet protocol
DHCP

All these technologies embedded into a Linux embedded microcomputer board (like the raspberry pi). A wireless router/hub would DHCP an address to each unit embedded with IEEE 802.11 embedded controller.
Long range IP
But 802.11 is specified to work within 100 metres. 800, 2.5 and 5 GHz are microwave RF spectrum that require line-of-sight connection. That would
There are various strategies to overcome the range

Use a GSM or telephony-embedded/enabled controller and subscribe each unit with the phone company. This is the field of telematics.

Use a long-range directional mother-hub, with a arrays of antennae beaming into local hubs which can also act as repeaters to connect to yet farther hubs. https://en.wikipedia.org/wiki/Long-range_Wi-Fi.
Effectively, that would be setting up your own mini-telephony network.


I want to say that the industry practice is Telematics for long-ranged connectivity (because I used to work for a telematics company connecting cars across the US). A well-known telephony company that also engages in telematics is Verizon.
But if your SAUs do not travel more that a 100 metres away from the hub (or using extender/repeater hubs for 200 - 300 metre connectivity),
your solution would be

an IEEE-802.11 hub with a telephony modem. Only the telephony-enabled modem needs to subscribe to the phone company. Each SAU is DHCP'd to a hub.

I have a little write-up on NAT and DHCP: https://stackoverflow.com/questions/1982222/how-do-two-computers-connect-to-same-external-address-through-nat/1985181#1985181.
You can speak to Verizon (or AT&amp;T, Orange. T-Mobile ) on using telematics modem with their networks.
A single mother-ship
Another solution is, if your operation can be designed such that updates need to be performed only every 1 - 10 minutes, depending on the vastness of your solar array field, you could have a single telematically enabled mother-ship or rover, that roves to exchange information with each hub its passes by.
But hey, if updates are necessary only hourly, your rover needs to return to base once every hour, without even needing telematic connectivity. For redundancy and quality reasons, you certainly should have more than one rover.
However, I think that telephony-enabled hubs (like a data-plan enabled android/iphone) DHCP'ing each SAU is the most effective way.