>I assume there's no way to specify different QCIs for data packets or even the whole connection ? That's all specified by the closed source radio firmware?

From the application layer? I don't believe so outside of the phone's native dialer/closed source firmware.

>If I'm reading things right, it implies that IMS (eg modern SMS/MMS running over IP) actually uses a different data channel that gets a higher priority?

I believe all IMS traffic is going to be higher priority regardless of if that's voice or SMS. They're both carrier-provided SIP messaging so if SMS over IMS is configured, it would use the same APN, go through the same CSCFs, and get priority. It's all the same PHY connection though. There's not a fully separate set of wireless channels for voice and data like it was in the CDMA standard where there were CDMA carriers for voice and EVDO carriers for 3G data.

You wouldn't be able to just host your own SMS though. You'd need a private APN from the network operator to do anything like that. Other systems hosted by the operator (HSS and MME) are what allow you onto the network.

Thank you for the reply! I'm trying to tease out what the limits of code on the application processor can do. By "data channel", I meant logical IP network.

Is it correct to say that IMS runs completely on/behind the locked down radio firmware, with the application processor then just getting access to an API that deals in high level "text messages" ? As opposed to the alternative where the servers I set in APN->MMSC/MMS Proxy are used directly by software on the application processor... Which I assume is not the case? And if I set MMSC to my own server, the resulting IP packets wouldn't be routed to the Internet because they're transmitted on a separate IP network from the application-processor-facing Internet access?

So barring some feature of the BP<->AP API to do so, there would be no way for software running on the AP to set various priorities on its own Internet-bound packets?