I am working with VoLTE capable android devices. When a device attaches to LTE it automatically gets PDN connectivity to APN1 , which is for Internet access. Immediately after that, the device requests PDN connectivity to the IMS APN (APN2). After this procedure completes, the device is connected to two different APNs simultaneously, has different IP addresses for the two APNs and can send traffic simultaneous on both "connections".
Q: I would like to understand how Android (4.1.2 in my case) actually implements this (?)
I assume that these are two different interfaces, but netcfg (adb shell) shows only one interface up, the one for APN1. The one for APN2 is nowhere to be found. It is, however, active and working because the device is sending IMS signalling on it (I am 100% sure of that). As a result, I cannot capture traffic (tcpdump) or add routing rules to ping specific IP addresses via APN2.
Answer
I think the reason why you can't see and access the IMS connection from your Android Application is probably clear but maybe not the mechanism that prevents you from seeing it.
The reason why the Operator would not want you to access the IMS connection is that this is used for call and session connection set up and take down in an IMS network. Allowing untrusted users direct access to this would open the door for lots of interesting and uncontrolled behaviour that could seriously compromise the operators network (denial of service attacks for instance).
How Android keeps visibility of this connection away from you is not as obvious. I think the best way to view it is to think of an LTE enabled Android device as being made up of two main components:
- An LTE phone/data terminal
- A linux based computer which is running the Android framework
The 'phone' part exposes certain functionality to the 'Android' part via defined interfaces - see the following link:
http://www.kandroid.org/online-pdk/guide/telephony.html
For obvious security reasons the 'phone' side in 2G and 3G devices exposes a relatively simple and very limited set of interfaces. For example, even though the 'phone' part itself contains all the functionality necessary to set up calls, negotiate radio resource usage etc, it does not provide an API to allow the Android application observe or manipulate these mechanisms or messages, beyond a limited set of defined interactions for basic call set up etc.
In the 3G world the detail of the mechanism to send a call setup message is thus hidden from the Android application - it can make a high level request to set up a call, but it can't actually control the GSM or 3G signalling to request rails resources, send the initial call message etc . In LTE to ensure this also stays hidden the Android application is not given access to the IMS connection and I think this is the observed behaviour you are probably referring to.