APNs in MCPTT smartphone

LTE smartphones provide mobile broadband connection to Internet. The prerequisite is that the UE has correct settings, which depend on the mobile operator. Nowadays device vendors and operators have made the use of mobile data so easy that usually users do not need to do any manual configuration. Each smartphone has an internet APN (Access Point Name) configuration, which matches with the operator's network configuration. In general certain APN configuration allows UE to connect (when included in subscription) to certain IP network called packet data network (PDN). So, smartphones know operator's internet APN setting, which enables UE to connect to Internet.

Operators have also other APNs and respective PDNs, which offer operator specific services. Some of those services are standardized. On old, still existing service is MMS (Multimedia Messaging Service). MMS is supported by all smartphones and probably automatically configured in all devices and networks. The question is just that does anybody really use MMS anymore, while there are more widely used messaging services such as WhatsApp, Facebook Messenger and iMessage. Another operator service behind own APN is VoLTE (Voice over LTE). VoLTE usage is actually increasing when more are more operators enable VoLTE in their networks. People are still dependent on calling telephone numbers even though smartphones and Internet services allow to make voice over IP calls with multiple different apps such as Skype, Viber and Facetime Audio. So, let's forget the MMS (if user does not use it, there is no impact on UE's network connections) and focus on internet access and VoLTE services. Smartphone has at least active IP connection to Internet and optionally also active IP connection to operator's VoLTE service. VoLTE is accessed via so called IMS APN.

The figure below shows on top a VoLTE smartphone having two connections for VoLTE and Internet access services. At bottom there is a so called CS fallback (CSFB) UE, which makes any operator voice calls in 3G or 2G networks using traditional CS voice service. The CSFB UE has just one IP connection to Internet.

PDN connections of commercial LTE smartphones.

Mission critical push to talk (MCPTT) architecture specification 23.179 defines additional use of APNs for MCPTT service. UE must of course know the APN configuration before it can connect to MCPTT service. The APN information can be made available to the UE for example via UE pre-configuration.

1) One option is that there is a dedicated APN for mission critical services. One clear benefit would be enhanced security, when mission critical services are separated from all other services with dedicated PDN.

2) 3GPP also suggests that mission critical functions can be separated to three different PDN connections as listed below. This would cause quite a lot additional complexity, while the benefits are questionable.
  • Mission critical identity management service APN and PDN
  • Mission critical common core services APN and PDN
  • Mission critical PTT service APN and PDN
3) Third model for MCPTT is to share APN and PDN connection with other services that have compatible QoS. 3GPP gives one example based on shared IMS APN in case same operator provides VoLTE and MCPTT services.

One could consider that separating MCPTT service from all other services is important, but then again solution should be fairly simple. So the first option could be used. This is depicted in the figure below.
MCPTT UE with dedicated APN for MCPTT service.

Are there any issues with the model shown above?

Each active PDN connection consumes at least one default EPS bearer from UE resources. This is important to note, because LTE device can have only limited amount of data radio bearers (DRB) and respective EPS bearers. LTE UE informs network about its capability support multiple data radio bearers with feature group indicators (see 36.331). Every LTE device supports at minimum 4 data radio bearers and in maximum 8 data radio bearers. 8 bearers is commonly supported in modern LTE smartphones so in principle there is possibility to have simultaneously active connections to multiple PDNs. In practice this is not so simple for service providers to use multiple APNs and PDN connections for single subscriber.

MCPTT UE client can be implemented as software application. Thus it could be installed on any commercial smartphone. Applications can easily access the UE hardware resources like touchscreen, microphone, speaker and any physical buttons. So, user interface for MCPTT can be implemented to basically any modern smartphone. And then the application only has to request connection to MCPTT APN(s) in order to access the PDN(s) providing mission critical services. This is easy - or is it?

Let's consider Android OS, which is the dominating smartphone OS (87% market share 2016 Q3 according to IDC). Those, who are familiar with Android smartphone settings, may have noticed that user can configure different APN settings to Android, but only one data APN setting can be active. So user cannot activate multiple data APNs for Android applications. There is also another APN configurable by user, but it is for the operator MMS service. Then we know that VoLTE smartphones use dedicated APN for the VoLTE service. This is however implemented so that the APN is standardized by GSM Association (so called IMS well-known APN defined in IR.88) and therefore there is no need to configure APN for VoLTE service.

Although Android does not support OS level capability to configure multiple data APNs for applications, could application developer implement application specific APN? Now this is actually the main problem. Applications have to have permission to perform different actions, but the permission to define and modify APN settings (WRITE_APN_SETTINGS) is not available for 3rd party applications. Only the Android system tools can modify APN.

As mentioned, 3GPP has also considered that the IMS APN could be shared between VoLTE and MCPTT. However IMS APN is tightly integrated to VoLTE and 3rd party applications do not have any access to IMS APN connection either.

Conclusion is that operator cannot implement MCPTT service to be used by commercial smartphones so that MCPTT would have dedicated APN and internet would be accessed via another APN.

Now someone thinks that MCPTT is a service for users, who always require special rugged devices with dedicated PTT button and highly secure HW and modified secure OS. Yes, some user groups will require such devices. In that case, the device vendor can implement tightly integrated MCPTT application, which has permissions to use dedicated MCPTT APN, while other data applications can use another data APN (see the previous figure). This is possible approach, but if MCPTT service is designed only for such devices, then there is no easy "fast track" option for MCPTT deployments based on existing commercial devices.

There is still another approach, which allows to use existing smartphones with 3rd party MCPTT application. And this model could be actually even better option for secure connection to Internet. The idea is that the single data APN in a smartphone connects to MCPTT operator's PDN, which offers mission critical services such as MCPTT as well as secure connection to Internet. This mission critical PDN can have enhanced firewalls, malware detection and content filtering in addition to the UE based security. The model with single data APN is depicted below. This enables use of both commercial smartphones and special rugged, secure public safety smartphones.

MCPTT UE connecting to Internet via "mission critical" PDN. 

Comments

  1. Hi Mika, Thank you for the detailed explanation. I actually have a totally different case here. We want to have a set of ims+MCPTT AS connecting to EPC, separating from carrier's IMS+TAS system. Assume carrier agrees to provide an dedicated APN to link to our own IMS system, is it technically viable? What need to be done to enable a dedicated MCPTT apn and an internet APN both active in an android phone? Does handset need any modifications besides the new APN configuration must be made to known to the handset? Thank you very much in advance!

    ReplyDelete
    Replies
    1. From UE point of view this could be possible, if the dedicated IMS/MCPTT service does not depend on UE chipset capabilities. I'm a bit struggling with the concept that "carrier agrees to provide an dedicated APN to link to our own IMS system". Where is PGW? Where is PCRF? Do you expect to have dynamic QoS for MCPTT?

      Delete
  2. Hi Mika, it seems to me that there's significant gap between what 3GPP standardized and what does market need. I believe that we as a mission critical network service provider need to have both options available (special rugged devices and commercial devices, also considering avoidance of the vendor locks) as there are different end users with different needs (e.g. firemen and city major in/out crisis time), while using the same QoS and thus APNs. IMO the only way is to have a dedicated MCPTT APN (need to use QCIs different to IMS and "internet" APNs as per 23.203) and thus I believe that the tools to use it (OS dev? change of policy for 3rd party apps?) must be provided. Or will we end up with certain users (with commercial devices) using missing critical network while on "best effort QoS"?
    If I understood you correctly, then the last article is about using "internet" APN - but then we have QCI 6, 8 or 9 for default bearer only so why would there be QCI 69? Even if that would be QCI 5, the QoS characteristics won't be up to the task.

    ReplyDelete
    Replies
    1. The last option could be the "dedicated MCPTT APN" with default bearer QCI70. MCPTT signalling could use QCI69 dedicated bearer (and audio media QCI65).

      Delete
  3. Hi Mika, I believe we need both dedicated/ruggedized devices and commercial devices while sticking with the QoS concept as defined by 23.203 i.e. use of MCPTT dedicated APN so the means to use 4 APNs in parallel shall be provided (i.e. MMS, IMS, "internet", MCPTT/MCX) device agnostically.
    What is Nokia's approach here with TDtech devices? Also did I understand last paragrpah talking about the use of "internet" APN for all the traffic (i.e. QCI 6, 8 or 9; or in fact any QCI) and basically ignoring QCIs as per 23.203? Not event thinking about different implementations for roaming (yes, planned even for MC users) and issues on transport layer?

    ReplyDelete
    Replies
    1. I expect that ruggedized public safety devices will support multiple APNs. But what is the motivation for vendors to implement more complex devices for consumers?

      I do not comment Nokia approaches here.

      Delete
  4. These ways are very simple and very much useful, as a beginner level these helped me a lot thanks fore sharing these kinds of useful and knowledgeable information.
    Texting API
    Fitness SMS
    Mobile Marketing Companies
    Sms Whitelabel Solutions

    ReplyDelete

Post a Comment

Popular posts from this blog

Public Safety prioritization

Mission Critical Push To Talk and EPS bearers

Spectrum