Access Point Name (APN) identifies a packet data network (PDN) that is configured on and accessible from the packet core (eg. GGSN). APNs are similar to a DNS name of the packet core and its composed of 2 parts.
• The APN Network Identifier which defines the external network or service that the user wishes to connect to via the packet core.
• The APN Operator Identifier which defines in which mobile network the packet core is located.
The APN that a mobile user is allowed to use is either programmed in the phone, or it could be sent over the air (OTA) via SMS. If an invalid APN is used then the PDP context request would be rejected with Invalid APN cause.
The networks of today are capable of handling any APN name and in fact recently I read some operator will allow any APN name to be used (PS: I cant remember details so please feel free to add link in the comment if you know). The reason for any APNs is that users use mobiles that were used on other networks which would have their APN settings, so the operator allows them to use any APN and then send OTA message to provide new settings.
The problem starts on these devices of today, even though you may say that you dont want to use operator data (especially while roaming), it still uses data and if the user does not have a good data plan then he may end up running a huge bill. See a discussion on this topic here and here.
From operators point of view, once they have sent setting OTA then they dont send it again. The users have come up with a workaround that they can use an invalid APN name and that would not connect to the operators network and incur data costs. The problem is that since the PDP Context request was now rejected, the device retries it when the device tries to use data again (mostly when there is no WiFi due to user being out and background apps are still running). This can cause loads of unnecessary signalling (for establishing PDP context).
In a situation like this, Martin Prosek from Telefonica, Czech Republic, mentioned that they have introduced 'PDP Context Parking'. They accept the PDP context request even though the APN is invalid but redirect the user to a default page where the user has many options like name of correct APN for someone using wrong APN by mistake, possiblity to buy 'bolt-ons' so they can use data over the mobile network and in some cases simply some free data allowance so that the users can get a feel of mobile data usage. This helped Telefonica O2, Czech Republic, reduce signaling and improve pdp connection success rate
I think this is a great idea and if someone has more information on this or personal experience, please feel free to add.
Yes, the feature 'apn parking' or 'apn mismatch re-route' is configured increasingly in asia. most of the xgsn/epc vendors are able to do though Cisco seems to be the pioneer of the idea..
ReplyDeleteHello, Zahid.
ReplyDeleteThanks a lot for sharing your passin and congratulations for the quality of your analysis.
When I combine your analysis about "pdp context parking", the content of your page http://www.3g4g.co.uk/Tutorial/ZG/zg_pdp (which is by the way one of the clearest description I have seen about what PDP context can be), together with my view on some new services needs, I deduct that the resolution for APN MUST be enhanced. So, Connectivity Access Networks MUST allow any APN name to be used. I explain. Today, take "Internet" APN, it is much difficult to reach a specific "application cloud" within the internet. Today, the PDN is "internet", but it should be the "application cloud" which should be associated with a specific PDN. End-users will have a growing need to access various application clouds (PDNs) from their browser (so, from TE, not just from ME !), with the additional constraint that they will only be allowed to do so if they present to each PDN a registered PDP address (PDP source IP address). Considering that such services requests need to reach the GGSN/PGW, in order to assure further correct routing towards each PDN over the Gi interface, the best GTP signaling information to make this feasible is the "APN". Unless you have a better idea !. Kind regards
Hi!
ReplyDeleteNot related to your current post, but this article -
http://www.3g4g.co.uk/Tutorial/ZG/zg_pdp
I have read in this article and other articles on internet that deactivating a primary PDP shall deactivate all associated secondary PDP contexts. However, I could not find this explicitly mentioned in the 3G specs. Also why should secondary PDP be deactivated if primary goes away? I know primary and secondary are associated with each other, however once primary goes away the association can be broken and the UE/Network can continue using secondary.
The 'Secondary' context is tied to the 'Primary' context so it cannot be used which Primary is released. I was trying to think of a scenario where Primary would be released and secondary would still be active but not sure if I can come up with a scenario like that.
ReplyDeleteRegarding the specs reference, it is mentioned indirectly as follows:
23.060:9.2.4.1
If the MS deactivates the PDP context created by the PDP Context Activation Procedure, the Teardown Ind shall be sent.
The Secondary context is created by the Secondary PDP Context Activation procedure.
A little bit late but it's Telefonica O2 Germany who allow any APN name to be used.
ReplyDelete