I'm a bit confused on your question but what I think your getting at is that should you isolate communication method from the higher level code in your application.
The answer to that is yes, create an abstraction layer within your application and have that layer deal with communication to the device by whatever means you need (modem, IP, serial, whatever). This is probably best created by defining an interface that supports your needed communication calls and then create classes that implement that interface which do the work needed by the chosen communication method. This way your higher level code doesn't care what communication method is used other than having to choose one.
By using this method its rather easy to add communication methods to the software. Write the class that does the communication dirty work based on the operation of your device and add some method to select that communication method in the main application.
On the operating system front you will have to have code managing the low level details of communication to the device and as these details are very often dependent on the type of connection i don't see any gain by attempting to force connection management into the OS somehow, this just complicates administration. You may find some gain by daemonizing a "communication manager" and separating the rest of your application to simply view or process the data collected.
I don't get how you would expect any architecture on the application end would somehow create a situation where the device doesn't need to be updated to report via a new protocol as SMTP compliance, for example, absolutely would require new code on the device.