I understand the rationale and it’s appealing but the use of a Programmable Logic Controller on each buoy is not open for debate. Other functions are involved which (probably) don’t lend themselves to direct interface with a LoRa unit.
A buoy is a buoy is a floaty thing.
A device or node is a small piece of electronics.
Please stop calling buoys nodes - you could have 25 devices aka nodes on a buoy - it just confuses what is already a muddled set of concepts on the application of LoRaWAN.
If a PLC is needed for other things, that’s fine - but why channel sensor data via a PLC, or just snag the PLC only data via serial.
Not a problem. Not even with 4 nodes on a buoy, however I agree with @descartes you make this discussion harder by not calling things what they are from a LoRaWAN point of view.
The thing with the radio is a LoRaWAN end device (often called node) that periodically sends data to a LoRaWAN network server (NS) via a gateway. Gateways connect to an IP network but talk UDP or TCP to the LoRaWAN NS only. Not modbus tcp or any such protocol.
You can retrieve data from a LoRaWAN NS using integrations that are provided by the party running the network server. If you need another protocol you need to get the data there and translate it to your required format before sending it on.
There is an option to send data to the end device via the NS as well, however this is very limited (think 1 or 2 times a day, more will impact the number of end devices that can be deployed in an area).
That should not be an issue, however you will need to find an end device that talks the same protocol the PLC speaks when it attempts to send the data. I haven’t seen any using modbus tcp yet. I am sure someone will gladly design and build one for you at the right price.
it sounds like you need to customeized a Lorawan to TCP/IP device, with Class C communication, the good thing is it looks like you don’t need to take care about power consumption, compare to the PLC, the power used by Lorawan node is almost nothing.
I’m grateful to everyone for taking the time to explain the operation and nuances of LoRa to me. I have a better understanding of its capabilities - which are enormous - and limitations - of which there are a few. For the buoy project at hand, it would seem a more traditional approach is appropriate.
There are a company making LoRaWAN enabled buoy - wave action, temperature and a few other parameters.
I just can’t recall who they were (that is why I did not comment before), I think they were a South African lot, were running trails in Durban.
Maybe worth Googling.
Some times the mind are made up on kit and you can’t say the mind, it is like a rock 
Small picky point.
There have been many explanations of the nuances of LoRaWAN.
Whilst LoRaWAN uses LoRa, most everything related to LoRaWAN is not relavent to those who are just using LoRa.
Indeed, LoRa Point 2 Point, whilst off topic for this forum, seems like it may be super useful if the baby doesn’t get thrown out with the bath water!