Definition and Evolution
In 2G/3G terminology, PDP context (Packet Data Protocol Context) describes a set of packet data session parameters between the mobile terminal and the core network's packet domain, including APN, assigned IP address, QoS configuration, billing, and routing information. Entering 4G/5G, the concept corresponds to PDN connection (Packet Data Network Connection) and the binding relationships of default and dedicated bearers. Although in engineering jargon people still often say 'activate PDP,' the underlying implementation has unified to EPS bearer or 5G QoS Flow, but understanding the abstraction of 'context' helps troubleshoot cross-layer issues like 'registered on the network, but packets are not passing.'
Activation and Deactivation Process
After the module is powered on and completes network registration, the application layer or protocol stack initiates a PDP/PDN activation request. The core network completes authentication, policy control, and gateway selection, then returns IP configuration and DNS to the terminal. Deactivation may be initiated by the terminal or triggered by billing anomalies, core network release, prolonged inactivity, or mobility events. For IoT devices using short connections for reporting, it is necessary to clarify whether to release the bearer after each transaction to save power, or maintain a long connection to reduce signaling overhead; the two strategies have completely different impacts on core network signaling load and battery life.
Multiple Contexts and Multiple APNs
Some gateways or in-vehicle terminals need to access both the public network and private network simultaneously. In this case, the terminal may maintain multiple PDP/PDN connections, each corresponding to different APNs and routing tables. The module side needs to support multiple IP stacks or policy routing to avoid default route conflicts. During debugging, it is recommended to use routing tables or tools like `netstat` to check each interface's gateway and metrics to ensure that traffic flows through the correct interface. If there is only a single PDP but traffic needs to be 'split,' this is usually implemented via carrier-side policies or enterprise VPNs. The terminal side should not forcibly perform complex NAT to avoid inconsistencies with application layer expectations.
Engineering Practice Recommendations
Production firmware should record PDP activation failure cause codes and implement retry backoff, to avoid frantic retries in weak network environments that could overload both the module and the network simultaneously. For IoT SIM cards that require a fixed IP, the address should be verified against the contract after activation and used in conjunction with firewall whitelists. When using IPv6, attention must also be paid to prefix delegation length and neighbor discovery timeouts to prevent addresses from becoming invalid after waking from sleep while still being cached by applications.
How Bearer Parameters Map to Host Routes
A PDP context is a set of session parameters, not a cable that stays up forever. It holds at least the access-point name, the negotiated address, a quality-of-service class, and the charging id on the gateway side. In 2G and 3G it is called a PDP. In 4G the more accurate name is a PDN connection plus a default bearer. In 5G it is a PDU session. When people still say "activate the PDP," they usually mean asking the module to obtain a bearer that can forward IP. Activation success only means the core network accepted those parameters and assigned an address. It does not mean the application server allows the traffic, and it does not mean the host route already points at this interface.
In use, decide first how long this context should live. A short report can deactivate after the transaction, which saves the air interface and sometimes the cost of staying attached. The price is a fresh signaling exchange next time, and a slower first packet. A long connection leaves the context in place and uses an application heartbeat to keep mappings in the middleboxes. When several access points exist at once, each context has its own address and gateway. The host needs an explicit policy route. Otherwise the default route sends private-network traffic out the public one.
Cause-Code Retries and Stale Address Caches
Ignoring the failure cause code is the most common miss. Congestion, an unsubscribed access point, an authentication failure, and a network-initiated release should not share one retry interval. Redialing immediately on every failure fills both the module and the cell under weak coverage. Another error is for the application to freeze the first address it received. After sleep or deactivation the address changes, the socket still sends to the old one, and the symptom is "attached, but the service times out." A card with a fixed address should be checked, after activation, to see whether the address is still the one in the contract, not merely whether activation returned success.
An IPv6 prefix can expire after a long sleep. If the application connects before neighbor discovery finishes, that too is misread as a module fault. Opening a single context and then doing complicated address translation inside the module often disagrees with the source address the upper layer expects. How the quality class on the bearer maps to different services is covered in QoS and service flows. When the context is still there but the radio has already returned to idle, read that cross-layer behavior together with RRC states. An IP-only capture is not enough.
After activation, three things should be true at the same time: the address belongs to the pool in the contract, the DNS address works, and the host route sends the intended service into this context rather than into another interface. Looking only at "activation succeeded" misses the last two. Deactivation can be started by the terminal, or by the network after a long idle period or a policy release. If the application treats every release as a fault and retries without limit, it loops on a cause the network has already refused. When several contexts exist together, each needs its own failure count. A private-network failure should not tear down and rebuild the public one. If the address changes after wake from sleep, long-connection mappings already established are invalid and must be rebuilt. Waiting for the application timeout is how you discover it late. Writing the cause code, the address, and the route metric in the same log line is what separates a subscription problem, an address-pool problem, and a host routing problem. Once those three are recorded apart, retries no longer use one interval for every failure.