A PS subscription contains the subscription of one or more PDP addresses. Each PDP address is an element of a PDP context. The same PDP address may appear in one or more PDP contexts in the MS, the SGSN, the S-GW, the P-GW and the GGSN. Each PDP context may be associated with a TFT. At most one PDP context associated with the same PDP address may exist at any time with no TFT assigned to it. Every PDP context exists independently in one of two PDP states. The PDP state indicates whether data transfer is enabled for that PDP address and TFT or not. In case all PDP contexts associated with the same PDP address are deactivated, data transfer for that PDP address is disabled. Activation and deactivation are described in clause "PDP Context Activation, Modification, Deactivation, and Preservation Functions". All PDP contexts of a subscriber are associated with the same MM context for the IMSI of that subscriber.

The INACTIVE state characterises the data service for a certain PDP address of the subscriber as not activated. The PDP context contains no routeing or mapping information to process PDP PDUs related to that PDP address. No data can be transferred. A changing location of a subscriber causes no update for the PDP context in INACTIVE state even if the subscriber is GPRS-attached. Mobile-terminated PDP PDUs received in INACTIVE state by the GGSN may initiate the Network-Requested PDP Context Activation procedure if the GGSN is allowed to initiate the activation of the PDP context for that PDP address. Otherwise, mobile-terminated PDP PDUs received in INACTIVE state invoke error procedures in the P-GW or GGSN relevant to the packet data network protocol, for example, an IP packet is discarded and an ICMP (see RFC 792) packet (error notification) is returned to the source of the received packet. Other error procedures may be introduced on the application level, but this is outside the scope of the present document. The MS initiates the movement from INACTIVE to ACTIVE state by initiating the PDP Context Activation procedure.

In ACTIVE state, the PDP context for the PDP address in use is activated in the MS, SGSN and GGSN when using Gn/Gp, or in the MS, SGSN, S-GW and P-GW when using S4. The PDP context contains mapping and routeing information for transferring PDP PDUs for that particular PDP address between the MS and the P-GW or GGSN. The PDP state ACTIVE is permitted only when the mobility management state of the subscriber is STANDBY, READY, PMM IDLE, or PMM CONNECTED. The Iu interface radio access bearer may or may not be established for an active PDP context. An active PDP context for an MS is moved to INACTIVE state when the deactivation procedure is initiated. All active PDP contexts for an MS are moved to INACTIVE state when the MM state changes to IDLE or PMM DETACHED.

This clause describes the procedures to enable a GPRS-attached MS to initiate the activation, modification, and deactivation functions for a PDP context in the MS, the SGSN, the S-GW and the P-GW or GGSN. In addition procedures to enable a P-GW or GGSN to request the activation, modification and deactivation of a PDP context to a GPRS-attached subscriber are described. An MS that activates Primary PDP Context(s) of PDP Type Non-IP shall not activate Secondary PDP Contexts for such PDP Context(s). Upon receiving an Activate PDP Context Request message or an Activate Secondary PDP Context Request message, the SGSN shall initiate procedures to set up PDP contexts. The first procedure includes subscription checking, APN selection, and host configuration, while the latter procedure excludes these functions and reuses PDP context parameters including the PDP address but except the QoS parameters. Once activated, all PDP contexts that share the same PDP address and APN shall be managed equally. At least one PDP context shall be activated for a PDP address before a Secondary PDP Context Activation procedure may be initiated. When the MS performs an RA update procedure to change from a release 99 to a release 97 or 98 system, only one active PDP context per PDP address and APN shall be preserved. This PDP context is selected taking the QoS profile and NSAPI value into account. When the SGSN is using the S4 interface to an S-GW for a PDP Context, EPS Bearer procedures will be used. The EPS subscription context includes a mandatory EPS subscribed QoS profile for the default bearer of each subscribed APN. If the S4-SGSN has received an EPS subscribed QoS profile and the first PDP context to a given APN is activated, the S4-SGSN disregards the QoS requested by the MS and sends the EPS subscribed QoS profile for this APN to the S-GW. For MSs, for which the S4-SGSN has not received an EPS subscribed QoS profile per APN, the S4-SGSN treats MS originated QoS requests the same as the Gn/Gp SGSN. For MSs, for which the S4-SGSN has not received a subscribed APN-AMBR per APN, the S4-SGSN provides APN-AMBR to the Serving GW and PDN-GW. Details on mapping MBR to APN-AMBR are specified in Annex E of TS 23.401. The E-UTRAN capable MS shall not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS shall not modify the QoS of the PDP context created by the PDP Context Activation Procedure. When the E-UTRAN capable MS is activating the first PDP context with the PDP Context Activation Procedure, the MS shall request for the subscribed QoS profile, but the MS may request for subscribed, interactive or background traffic class. If the EPS subscribed QoS profile information is available to the PDN-GW (e.g. if PCC is deployed) and the PDN-GW is connected to an Gn/Gp SGSN, the PDN-GW shall modify the requested QoS according to the EPS subscribed QoS profile during the PDP Context Activation Procedure. The non E-UTRAN capable MS should not deactivate the PDP context created by the PDP Context Activation Procedure unless all PDP contexts for the same PDN connection are to be deactivated. The MS should not modify the QoS of the PDP context created by the PDP Context Activation Procedure as long as the MS can achieve the same result using a different PDP context than the PDP context created by the PDP Context Activation Procedure. During the PDP Context Activation Procedure the bearer control mode, applicable to all PDP Contexts within the activated PDP Address/APN pair, is negotiated. The Bearer Control Mode (BCM) is one of 'MS_only' or 'MS/NW':

• When 'MS_only' the MS shall request any additional PDP contexts for the PDP Address/APN pair through the Secondary PDP Context Activation Procedure. Session Management procedures described in 9.2 apply with the following restrictions:
  • The P-GW or GGSN shall not initiate any Network Requested Secondary PDP Context Activation.
  • The P-GW or GGSN shall not initiate any TFT operation.
  • The P-GW shall reject any MS request for a secondary PDP context activation that is received without a TFT.
  • For a TFT, when the MS uses the direction attribute, the MS shall ensure that there is at least one packet filter for the uplink direction (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure).
• When 'MS/NW' both the MS and the P-GW or GGSN may request additional PDP contexts for the PDP Address/APN pair. The MS shall use the Secondary PDP Context Activation Procedure. The P-GW or GGSN shall use the Network Requested Secondary PDP Context Activation Procedure. The MS shall, when modifying the QoS of a PDP context, include a TFT with at least packet filter identifiers to indicate which packet filters in the TFT are associated with the QoS change.
  For 'MS/NW' the session Management procedures described in clause 9.2 apply with the following restrictions:
  • The MS shall not modify the QoS of a PDP context until this PDP context is associated with a TFT containing packet filters set by the MS. If the TFT also contains packet filters set by the P-GW/GGSN, the MS is only allowed to modify the bit rate parameters in the QoS profile of that PDP Context;
  • The MS shall not initiate any Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;
  • The P-GW/GGSN shall not initiate any Network Requested Secondary PDP Context Activation without sending a TFT containing at least one packet filter for the uplink direction;
  • The MS shall not add a TFT to a PDP context that was established without a TFT;
  • The MS shall not delete the TFT from a PDP context that is associated with a TFT;
  • The network shall not delete the TFT from a PDP context that is associated with a TFT unless the PDP context was created by the PDP Context Activation Procedure;
  • Only the entity that sets a packet filter in the TFT (either MS or P-GW/GGSN) is allowed to modify or delete this packet filter;
  • For each TFT, the MS and the network shall ensure that among the packet filters under own control there is at least one packet filter for the uplink direction, or no own packet filter at all (unless the TFT is for the PDP context that has been established with the PDP Context Activation Procedure);
  • For each packet filter the MS and the network shall indicate whether it corresponds to uplink, downlink or bi-directional traffic flow(s).
• The P-GW/GGSN shall ensure that for all PDP contexts of the same APN/PDP address pair a valid state for the TFT settings (as defined in clause 15.3.0) is maintained.

The MS indicates support of the network requested bearer control through the Network Request Support UE (NRSU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The SGSN indicates support of the network requested bearer control through the Network Request Support Network (NRSN) parameter. If the NRSN is not included in the Update PDP Context Request message from the SGSN, or the SGSN does not indicate support of the network requested bearer control, the GGSN or P-GW shall, following a SGSN-Initiated PDP Context Modification (triggered by SGSN change), perform a GGSN or P-GW-Initiated PDP Context Modification to change the BCM to 'MS-Only' for all PDP-Address/APN-pairs for which the current BCM is 'MS/NW'. An S4-based SGSN shall apply the BCM 'MS/NW' whenever the S4 is selected for a certain MS. The MS indicates support of the extended TFT filter format through the Extended TFT Support UE (ETFTU) parameter, which is applicable to all PDP contexts within the same PDP address / APN pair. The network indicates the support of the extended TFT filter format for all PDP contexts within the same PDP address / APN pair through the Extended TFT Support Network (ETFTN) parameter. Upon receiving a Deactivate PDP Context Request message, the SGSN shall initiate procedures to deactivate the PDP context. When the last PDP context associated with a PDP address is deactivated, N PDU transfer for this PDP address is disabled. An MS does not have to receive the (De ) Activate PDP Context Accept message before issuing another (De-)Activate PDP Context Request. However, only one request can be outstanding for every TI. By sending a RAB Release Request or Iu Release Request message to the SGSN, the RAN initiates the release of one or more RABs. The preservation function allows the active PDP contexts associated with the released RABs to be preserved in the CN, and the RABs can then be re-established at a later stage. An S4-based SGSN shall for all active PDN Connections for a certain MS use either S4 or Gn/Gp. This is achieved by the SGSN rejecting a PDP Context activation violating this:

• If an MS is sending an Activate PDP Context Request for an APN using Gn, the activation will be rejected by the SGSN if a PDP Context using S4 already exists for this MS;
• If an MS is sending an Activate PDP Context Request for an APN using S4, the activation will be rejected by the SGSN if a PDP Context using Gn already exists for this MS.

The list of QoS parameters that the PCEF may change, e.g. ARP or APN-AMBR or both, either based on local policy or based on PCRF interactions is described in clause 9.2.3. In a roaming scenario, based on local configuration, the S4-SGSN may downgrade the ARP or APN-AMBR and/or remap QCI parameter values received from HSS to the value locally configured in S4-SGSN (e.g. when the values received from HSS do not comply with services provided by the visited PLMN). The PCEF may change the QoS parameter values received from the S4-SGSN based on interaction with the PCRF or based on local configuration. Alternatively, the PCEF may reject the bearer establishment. If case S4 is selected for a certain MS the SGSN shall not modify the EPS bearer level QoS parameters received from the PDN-GW during establishment or modification of a default or dedicated bearer (except when the conditions described in NOTE 14 apply). Based on local configuration, the SGSN may reject the establishment or modification of a default or dedicated bearer only in the case of roaming when the bearer level QoS parameter values do not comply with a roaming agreement.

The following text describes the general principles used by an SGSN using S4 when mapping between PDP Contexts and EPS Bearers. The MS is using PDP Context Activation, Modification and Deactivation functions, and PDP Contexts are therefore used between MS and SGSN. An SGSN using Gn/Gp only will use these procedures towards GGSNs as well. An SGSN using S4 will for a specific PDP Context towards an MS map these procedures into equivalent procedures using EPS Bearer towards S-GW and P-GW. EPS Bearer procedures will not be used between MS and SGSN. The following principles are to be used:

• 1:1 mapping between one PDP context and one EPS Bearer;
• 1:1 mapping between NSAPI and EPS Bearer ID;
• The P-GW treats an MS-initiated request, e.g. a Secondary PDP Context Activation Request, according to the UE requested bearer resource modification procedures in TS 23.401;
• PDN-GW and Serving GW need to be RAT aware to allow for 2G/3G specific handling of EPS bearers, e.g. MS initiated secondary PDP Context activation must make the P-GW to activate a new EPS bearer.
• The QoS profiles of the PDP context and EPS bearer are mapped as specified in TS 23.401.
• If the S4-SGSN receives the EPS subscribed QoS profile per subscribed APN from the HSS, the S4-SGSN enforces this QoS for the first PDP context which is activated to the given APN. Otherwise the S4-SGSN restricts requested QoS according to the QoS Profile Subscribed which defines the maximum QoS per subscribed APN.

PDP addresses can be allocated to an MS in four different ways:

• the HPLMN operator assigns a PDP address permanently to the MS (static PDP address);
• the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP address);
• the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP address); or
• the PDN operator or administrator assigns a permanent or dynamic PDP address to the MS (External PDN Address Allocation).

It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be used. The HPLMN operator may assign a static PDP address in the PDP context subscription record. An MS implemented according to this version of the protocol does not support static PDP addresses, which are permanently configured in the MS and sent by the MS within the PDP context activation request. The handling of static addresses, which are sent by the MS, is retained in the SGSN in order to ensure backwards compatibility for MSs implemented according to earlier protocol releases. For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to. When dynamic addressing from the HPLMN or the VPLMN is used, it is the responsibility of the GGSN or P-GW to allocate and release the dynamic PDP address. When External PDN Address Allocation is used, the following applies for GGSN:

• the PLMN may obtain a PDP address from the PDN and provide it to the MS during PDP context activation, or the MS may directly negotiate a PDP address with the PDN after the PDP context activation procedure is executed. If the PLMN provides the address during PDP context activation in case of External PDN Address Allocation, then it is the responsibility of the GGSN and PDN to allocate, renew and release the dynamic PDP address by means of protocols such as DHCP or RADIUS. If DHCPv4/v6 is used, the GGSN provides the function of a DHCPv4/v6 Client. If RADIUS is used, the GGSN provides the function of a RADIUS Client. If the MS negotiates a PDP address with the PDN after PDP context activation in case of External PDN Address Allocation, it is the responsibility of the MS and the PDN to allocate and release the PDP address by means of protocols such as DHCP or MIP. In case of DHCPv4, the GGSN provides the function of a DHCP Relay Agent as defined in RFC 2131 and RFC 1542. In case of MIP, the GGSN provides the function of a Foreign Agent as defined in RFC 3344.

External PDN Address Allocation (including DHCP functionality) in P-GW is specified in TS 23.401. Only static PDP addressing is applicable in the network-requested PDP context activation case. PDP types IPv4, IPv6 and IPv4v6 are supported. A PDP Context of PDP type IPv4v6 may be associated with one IPv6 prefix only or with both one IPv4 address and one IPv6 prefix. PDP types IPv4 and IPv6 are utilised in case the MS and/or the GGSN or P-GW support IPv4 addressing only or IPv6 addressing only; or operator preferences dictate the use of a single IP version type only, or the subscription is limited to IPv4 only or IPv6 only. In addition, PDP types IPv4 and IPv6 are utilised for interworking with nodes of earlier releases. The way that the MS sets the requested PDP type may be pre-configured in the device per APN. Unless otherwise configured (including when the MS does not send any APN), PDP types are set by the MS as follows:

• An MS, which supports Non-IP data and wants to use Non-IP data, shall request for PDP type Non-IP.

Otherwise:

• An MS, which is IPv6 and IPv4 capable, shall request for PDP type IPv4v6.
• An MS, which supports IPv4 addressing only, shall request for PDP type IPv4.
• An MS, which supports IPv6 addressing, shall request for PDP type IPv6.
• When the IP addressing capability of the MS is not known in the MS (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the MS shall request for PDP type IPv4v6.

During the PDP Context Activation procedure the SGSN compares the requested PDP type to the PDP type in the subscription records for the given APN and sets the PDP type as follows:

• If the requested PDP type is allowed by subscription, the S4-SGSN sets the PDP type as requested.
• If the requested PDP type is allowed by subscription and if the requested PDP type is IPv4v6, the Gn/Gp SGSN sets the PDP type as requested if the GGSN supports PDP type IPv4v6. Otherwise, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is based on the result of the check.
• If the requested PDP type is IPv4v6 and subscription data only allows PDP type IPv4 or only allows PDP type IPv6, the SGSN sets the PDP type according to the subscribed value. A reason cause shall be returned to the UE indicating that only the assigned PDP type is allowed. In this case the UE shall not request for another PDP context to the same APN for the other IP version during the existence of the PDP context.
• If the requested PDP type is IPv4 or IPv6, and either the requested PDP type or PDP type IPv4v6 are subscribed, the SGSN sets the PDP type as requested. Otherwise the PDP context activation request is rejected.
• If the requested PDP type is IPv4v6, and both IPv4 and IPv6 PDP types are allowed by subscription but not IPv4v6, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The MS should then initiate another PDP Context Activation procedure to this APN in order to activate a second PDP context with the other single address PDP type which was not allocated by the network.

The GGSN / PDN-GW may restrict the usage of PDP type IPv4v6 as follows:

• If the MS requests PDP type IPv4v6, but the operator preferences dictate the use of a single IP version only, the PDP type shall be changed to a single address PDP type (IPv4 or IPv6) and a reason cause shall be returned to the MS indicating that only the assigned PDP type is allowed. In this case, the MS shall not request another PDP context for the other PDP type during the existence of the PDP context.
• If the MS requests PDP type IPv4v6, but the operator uses single addressing per PDP context due to interworking with nodes of earlier releases, the PDP type shall be changed to a single address PDP type and a reason cause of "single address bearers only" shall be returned to the MS. In this case the MS should request another PDP context for the other PDP type to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated.

An MS of this release may request for PDP type IPv4v6 from a SGSN which does not support this PDP type. The SGSN treats a request for PDP type IPv4v6 as if it were a request for PDP type IPv4. To enable dual-stack connectivity for this case, the MS should request another PDP context for PDP type IPv6 to the same APN. The mechanism used to allocate an IPv4 address to an MS depends on the MS and the network capabilities. The MS may indicate to the network within the Protocol Configuration Options element that the MS wants to obtain the IPv4 address with DHCPv4 as defined in RFC 2131:

• the MS may indicate that it prefers to obtain an IPv4 address as part of the PDP context activation procedure. In such a case, the MS relies on the network to provide an IPv4 address to the MS as part of the PDP context activation procedure.
• the MS may indicate that it prefers to obtain the IPv4 address after the PDP Context Activation by DHCPv4. That is, the network does not provide the IPv4 address for the MS as part of the PDP context activation procedures but sets the PDP address as 0.0.0.0. After the PDP Context establishment procedure is completed, the MS initiates the IPv4 address allocation by using DHCPv4 (see details in TS 29.061 and RFC 2131).

If the MS does not send such an indication of address allocation preference, the network selects the IPv4 address allocation method based on per APN configuration. Both the network elements and MS may support:

1. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 and RFC 4039;
2. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736.