6.1.3 Session Management procedures

24.0083GPPCore network protocolsMobile radio interface Layer 3 specificationRelease 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1.3.0 General

The MS’s maximum number of active PDP contexts in a PLMN is determined by the lowest of the maximum number of Network Service Access Point Identifiers (NSAPIs) allowed by the protocol (as specified in subclause 10.5.6.2), the PLMN’s maximum number of PDP contexts in Iu or A/Gb mode and the MS’s implementation-specific maximum number of PDP contexts.

NOTE: Subclauses 6.1.3.1.3 and 6.1.3.2.2 specify how the MS determines the PLMN’s maximum number of PDP contexts in Iu or A/Gb mode.

6.1.3.1 PDP context activation

The purpose of this procedure is to establish a PDP context between the MS and the network for a specific QoS on a specific NSAPI. The PDP context activation may be initiated by the MS or the initiation may be requested by the network.

An MS attached for emergency bearer services shall only request a PDP context with request type set to "emergency". If there already is a PDN connection for emergency bearer services established, the MS shall not request an additional PDN connection for emergency bearer services. The MS shall not request emergency bearer services in A/Gb mode or in GERAN Iu mode.

If the MS has reached the maximum number of active PDP contexts (see subclause 6.1.3.0) and the upper layers of the MS request activation of additional PDP context, then the MS shall not send an ACTIVATE PDP CONTEXT REQUEST message or an ACTIVATE SECONDARY PDP CONTEXT REQUEST message to activate the additional PDP context. If the additional PDP context is a PDP context with type set to "emergency", then it may skip explicit deactivation to free PDP context resources and instead re-activate the necessary context(s) relying on network handling of abnormal cases as specified in subclause 6.1.3.1.5 case c). In either case it is an MS implementation option which PDP context(s) to re-use for emergency.

Each PDP address may be described by one or more PDP contexts in the MS or the network. The PDP Context Activation procedure is used to activate the default PDP context for a given PDP address and APN, i.e. a PDN connection, whereas all additional contexts associated to the same PDP address and APN are activated with the secondary PDP context activation procedure. An MS supporting S1 mode shall keep the default PDP context activated during the lifetime of the PDN connection. An MS not supporting S1 mode should apply the same behaviour (see 3GPP TS 23.060 [74]). When more than one PDP context is associated to a PDP address, there shall be a Traffic Flow Template (TFT), including one or more packet filters, for each or all but one context. The downlink and uplink packet filters are considered separately. If present, the TFT shall be sent transparently either from the MS via the SGSN to the GGSN to enable packet classification and policing for downlink data transfer in the GGSN or from the GGSN via the SGSN to the MS to be used in a network requested secondary PDP context activation procedure (see subclause 6.1.3.2) and enable packet classification and policing for uplink data transfer in the MS (see 3GPP TS 23.060 [74]).

For the purpose of requesting non-IP connectivity, the MS shall set the PDP type number in the Requested PDP address information element in the ACTIVATE PDP CONTEXT REQUEST message to "non IP". The MS supporting non-IP connectivity shall also support the extended protocol configuration options IE.

For the purpose of requesting IP address allocation the MS shall set the PDP type number in the Requested PDP address information element in the ACTIVATE PDP CONTEXT REQUEST message based on its IP stack configuration (e.g. the per APN settings specified in 3GPP TS 23.060 [74]) as follows:

a) An MS, which is IPv6 and IPv4 capable, and

– has not been allocated an IP address for this APN, shall set the PDP type number to "IPv4v6 address";

– has been allocated an IPv4 address for this APN and received the SM cause #52, "single address bearers only allowed", and is requesting an IPv6 address, shall set the PDP type number to "IPv6 address";

– has been allocated an IPv6 address for this APN and received the SM cause #52, "single address bearers only allowed", and is requesting an IPv4 address, shall set the PDP type number to "IPv4 address".

b) An MS, which is only IPv4 capable, shall set the PDP type number to "IPv4 address".

c) An MS, which is only IPv6 capable, shall set the PDP type number to "IPv6 address".

d) When the IP version capability of the MS is unknown 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 set the PDP type number to "IPv4v6 address".

On receipt of the ACTIVATE PDP CONTEXT REQUEST message sent by the MS, the network when allocating an IP address shall take into account the PDP type number, the operator policies of the home and visited network, and the user’s subscription data.

– If the MS requests PDP type IPv4v6, but the network configuration dictates the use of IPv4 addressing only or IPv6 addressing only for this APN, the network shall override the PDP type requested by the MS to a single address PDP type (IPv4 or IPv6). In the ACTIVATE PDP CONTEXT ACCEPT message sent to the MS, the network sets the PDP type number to either "IPv4 address" or "IPv6 address" and the SM cause to #50 "PDP type IPv4 only allowed", or #51 "PDP type IPv6 only allowed", respectively (see subclause 6.1.3.1.1).

– 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 network shall override the PDP type requested by setting the PDP type in the ACTIVATE PDP CONTEXT ACCEPT message sent to the MS to a single address PDP type. In the ACTIVATE PDP CONTEXT ACCEPT message sent to the MS, the network sets the PDP type number to either "IPv4 address" or "IPv6 address" and the SM cause to #52, "single address bearers only allowed" (see subclause 6.1.3.1.1).

The MS, in a pre release 8 network not supporting IPv4/v6, could encounter other network reactions:

– If the MS requests PDP type IPv4v6, and the PDP type is changed to PDP type IPv4 and no SM cause is included, the MS should request another PDP context for PDP type IPv6 to the same APN.

NOTE: Some networks can respond with ACTIVATE PDP CONTEXT REJECT with SM cause #28 "unknown PDP address or PDP type". In that instance, the MS can attempt to establish dual-stack connectivity by performing two PDP context activation request procedures to activate an IPv4 PDP context and an IPv6 PDP context, both to the same APN.

6.1.3.1.1 Successful PDP context activation initiated by the mobile station

In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts timer T3380. The message contains the selected NSAPI, PDP type number and requested QoS. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. The MS may indicate the support of Network Requested Bearer Control procedures, the support of local IP address in TFTs or the 3GPP PS data off UE status in the protocol configuration options information element. The MS supporting S1 mode shall indicate subscribed, interactive or background traffic class in the QoS requested. The MS not supporting S1 mode should indicate subscribed, interactive or background traffic class in the QoS requested. If there is a subscribed QoS profile available for the MS, the network may ignore the requested QoS and apply the subscribed QoS profile (see 3GPP TS 23.060 [74]).

The MS shall set the request type to "initial request" when the MS is establishing connectivity to an additional PDN for the first time, i.e. when it is an initial attach to that PDN. The MS shall set the request type to "handover" when the connectivity to a PDN is established upon handover from a non-3GPP access network and the MS was connected to that PDN before the handover to the 3GPP access network. If the MS is establishing connectivity for emergency bearer services it shall set the request type to "emergency" and not include an APN in the ACTIVATE PDP CONTEXT REQUEST message.

Upon receipt of the ACTIVATE PDP CONTEXT REQUEST message with request type set to "emergency" the network shall use the APN or the GGSN/PDN GW configured for emergency bearer services.

Upon receipt of an ACTIVATE PDP CONTEXT REQUEST message with a PDP type number "IPv4v6 address" in the Requested PDP address information element, the network shall on sending the ACTIVATE PDP CONTEXT ACCEPT message:

– include the SM cause information element with cause #50 "PDP type IPv4 only allowed", if the requested PDN connectivity is accepted with the restriction that only PDP type IPv4 is allowed; or

– include the SM cause information element with cause #51 "PDP type IPv6 only allowed", if the requested PDN connectivity is accepted with the restriction that only PDP type IPv6 is allowed; or

– include the SM cause information element with cause #52 "single address bearers only allowed", if the requested PDN connectivity is accepted with the restriction that only single IP version bearers are allowed.

If the MS receives the SM cause value #50 "PDP type IPv4 only allowed" or #51 "PDP type IPv6 only allowed" in the ACTIVATE PDP CONTEXT ACCEPT message, the MS shall not subsequently request another PDP context to get a PDP Type different from the one allowed by the network, until:

– all PDP contexts to the given APN are deactivated either explicitly between the MS and the network, i.e. PDP context deactivation procedure, or implicitly (without peer to peer signalling between the MS and the network) as a result of:

i) PDP context synchronization during routing area updating or service request procedure;

ii) PDP context deactivation initiated by the network,

iii) detach from GPRS services; or;

iv) a service request procedure is rejected with a cause which results in the MS entering state GMM-DEREGISTERED; or

– the PDP type which is used to access to the APN is changed.

NOTE 1: Request to send another ACTIVATE PDP CONTEXT REQUEST message with a specific PDP type comes from upper layers.

If the MS receives the SM cause value #52 "single address bearers only allowed" in the ACTIVATE PDP CONTEXT ACCEPT message, the MS should subsequently 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.

NOTE 2: If the MT and TE are separated, the MS might not be able to use SM cause #52 "single address bearers only allowed" as a trigger for activating a second single-IP-stack PDP context.

Upon receipt of an ACTIVATE PDP CONTEXT REQUEST message, the network selects a radio priority level based on the QoS negotiated and may reply with an ACTIVATE PDP CONTEXT ACCEPT message.

If the ACTIVATE PDP CONTEXT REQUEST message included a low priority indicator set to "MS is configured for NAS signalling low priority", the network shall store the NAS signalling low priority indication within the default PDP context.

If the network receives an ACTIVATE PDP CONTEXT REQUEST message with the same combination of APN and PDP type as an already existing PDN connection, and multiple PDN connections for a given APN are allowed, the network may retain the existing PDP contexts and proceed with the requested PDP context activation procedure.

Upon receipt of the message ACTIVATE PDP CONTEXT ACCEPT the MS shall stop timer T3380, shall enter the state PDP-ACTIVE. If the protocol configuration options information element is present, the network may indicate the Bearer Control Mode that shall be used, the network support of local IP address in TFTs, or the 3GPP PS data off support indication. If the protocol configuration options information element is not present or the Selected Bearer Control Mode parameter is not present in the protocol configuration options information element, the MS shall apply Bearer Control Mode ‘MS only’ for all active PDP contexts sharing the same PDP Address and APN. If the 3GPP PS data off UE status is "activated", the MS behaves as described in subclause 4.7.1.10. If the offered QoS parameters received from the network differ from the QoS requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP context deactivation procedure. If the Request type information element is not present, the network shall assume that the request type is "initial request".

NOTE 3: If the MS requested a value for a QoS parameter that is not within the range specified by 3GPP TS 23.107 [81], the network should negotiate the parameter to a value that lies within the specified range.

If the lower layers provide a L-GW Transport Layer Address value together with the ACTIVATE PDP CONTEXT REQUEST message and a PDN connection is established as a LIPA PDN connection due to the ACTIVATE PDP CONTEXT REQUEST message, then the SGSN shall store the L-GW Transport Layer Address value as the GGSN address in the PDP context of the LIPA PDN connection. If connectivity with the requested APN is accepted and the network considers this PDN connection a LIPA PDN connection, then subject to operator policy the SGSN shall include in the ACTIVATE PDP CONTEXT ACCEPT message the Connectivity type IE indicating "the PDN connection is considered a LIPA PDN connection".

If the lower layers provide a SIPTO L-GW Transport Layer Address value identifying a L-GW together with the ACTIVATE PDP CONTEXT REQUEST message and a PDN connection is established as a SIPTO at the local network PDN connection due to the ACTIVATE PDP CONTEXT REQUEST message, then the SGSN shall store the SIPTO L-GW Transport Layer Address value as the P-GW address in the PDP context of the SIPTO at the local network PDN connection.

If the lower layers provide a LHN-ID value together with the ACTIVATE PDP CONTEXT REQUEST message and a PDN connection is established as a SIPTO at the local network PDN connection due to the ACTIVATE PDP CONTEXT REQUEST message, then the SGSN shall store the LHN-ID value in the PDP context of the SIPTO at the local network PDN connection.

NOTE 4: The receipt of a LHN-ID value during the establishment of the PDN connection, during routing area updating procedure or during inter-SGSN handover can be used as an indication by the SGSN that the SIPTO at the local network PDN connection is established to a stand-alone GW (see 3GPP TS 23.060 [74]).

In A/Gb mode, the MS shall initiate establishment of the logical link for the LLC SAPI indicated by the network with the offered QoS and selected radio priority level if no logical link has been already established for that SAPI. If the offered QoS parameters received from the network differ from the QoS requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP context deactivation procedure. If the LLC SAPI indicated by the network can not be supported by the MS, the MS shall initiate the PDP context deactivation procedure.

In Iu mode, both the network and the MS shall store the LLC SAPI and the radio priority in the PDP context. If a Iu mode to A/Gb mode system change is performed, the new SGSN shall initiate establishment of the logical link using the negotiated QoS profile, the negotiated LLC SAPI, and selected radio priority level stored in the PDP context as in a A/Gb mode to A/Gb mode Routing Area Update.

An MS, which is capable of operating in A/Gb mode, shall use a valid LLC SAPI, while an MS which is not capable of operating in A/Gb mode shall indicate the LLC SAPI value as "LLC SAPI not assigned" in order to avoid unnecessary value range checking and any other possible confusion in the network. When the MS uses a valid LLC SAPI, the network shall return a valid LLC SAPI. The network shall return the "LLC SAPI not assigned" value only when the MS uses the "LLC SAPI not assigned" value.

NOTE 5: The radio priority level and the LLC SAPI parameters, though not used in Iu mode, shall be included in the messages, in order to support handover between Iu mode and A/Gb mode networks.

If a WLAN offload indication information element is included in the ACTIVATE PDP CONTEXT ACCEPT message, the MS shall store the WLAN offload acceptability values for this PDN connection and use the UTRAN offload acceptability value to determine whether this PDN connection is offloadable to WLAN or not.

At inter-system change from Iu mode to A/Gb mode, SM shall locally deactivate the active PDP context(s) if SM does not have the following parameters:

– LLC SAPI; and

– radio priority.

Upon receipt of the ACTIVATE PDP CONTEXT ACCEPT message with the Connectivity type IE indicating "the PDN connection is considered a LIPA PDN connection", the MS provides an indication to the upper layers that the connectivity is provided by a LIPA PDN connection.

6.1.3.1.2 Successful PDP context activation requested by the network

In order to request a PDP context activation, the network sends a REQUEST PDP CONTEXT ACTIVATION message to the MS and starts timer T3385. The message contains an offered PDP address. If available, the APN shall be included in the REQUEST PDP CONTEXT ACTIVATION message.

Upon receipt of a REQUEST PDP CONTEXT ACTIVATION message if an APN is indicated in the message and the timer T3396 is running for the APN, the MS shall stop the timer T3396, and then either initiate the PDP context activation procedure as described in the previous subclause or reject the activation request by sending a REQUEST PDP CONTEXT ACTIVATION REJECT message as described in subclause 6.1.3.1.4. If the REQUEST PDP CONTEXT ACTIVATION message did not contain an APN, then the MS shall stop the timer T3396 associated with no APN. The value of the reject cause IE of the REQUEST PDP CONTEXT ACTIVATION REJECT message shall indicate the reason for rejection, e.g. "insufficient resources to activate another context".

The ACTIVATE PDP CONTEXT REQUEST message sent by the MS in order to initiate the PDP context activation procedure shall contain the PDP address, PDP Type and APN requested by the network in the REQUEST PDP CONTEXT ACTIVATION message.

Upon receipt of the ACTIVATE PDP CONTEXT REQUEST message, the network shall stop timer T3385.

The same procedures then apply as described for MS initiated PDP context activation.

6.1.3.1.3 Unsuccessful PDP context activation initiated by the MS

6.1.3.1.3.1 General

Upon receipt of an ACTIVATE PDP CONTEXT REQUEST message the network may reject the MS initiated PDP context activation by sending an ACTIVATE PDP CONTEXT REJECT message to the MS. The message shall contain a cause code that typically indicates one of the following causes:

# 8: Operator Determined Barring;

# 26: insufficient resources;

# 27: missing or unknown APN;

# 28: unknown PDP address or PDP type;

# 29: user authentication failed;

# 30: activation rejected by GGSN, Serving GW or PDN GW;

# 31: activation rejected, unspecified;

# 32: service option not supported;

# 33: requested service option not subscribed;

# 34: service option temporarily out of order;

# 35: NSAPI already used. The network shall not send this cause code (see note 1);

# 50: PDP type IPv4 only allowed;

# 51: PDP type IPv6 only allowed;

# 57: PDP type IPv4v6 only allowed;

# 58: PDP type non IP only allowed;

# 65: maximum number of PDP contexts reached;

# 66: requested APN not supported in current RAT and PLMN combination;

# 95 – 111: protocol errors;

#112: APN restriction value incompatible with active PDP context; or

#113: Multiple accesses to a PDN connection not allowed.

NOTE 1: Pre-R99 network may send this cause code.

The network may include a Back-off timer value IE in the ACTIVATE PDP CONTEXT REJECT message. If the SM cause value is #26 "insufficient resources" and if the request type in the ACTIVATE PDP CONTEXT REQUEST was set to "emergency", the network shall not include a Back-off timer value IE.

If the Back-off timer value IE is included and the SM cause value is different from #26 "insufficient resources", #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed", #58 "PDP type non IP only allowed" and #65 "maximum number of PDP contexts reached", the network may include the Re-attempt indicator IE to indicate whether the MS is allowed to attempt a PDN connectivity procedure in the PLMN for the same APN in S1 mode, and whether another attempt in A/Gb and Iu mode or in S1 mode is allowed in an equivalent PLMN.

If the SM cause value is #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed" or #58 "PDP type non IP only allowed", the network may include the Re-attempt indicator IE without Back-off timer value IE to indicate whether the MS is allowed to attempt a PDP context activation procedure in an equivalent PLMN for the same APN in A/Gb or Iu mode using the same PDP type.

If the SM cause value is #66 "requested APN not supported in current RAT and PLMN combination", the network may include the Re-attempt indicator IE without Back-off timer value IE to indicate whether the MS is allowed to attempt a PDP context activation procedure in an equivalent PLMN for the same APN in A/Gb or Iu mode.

Upon receipt of an ACTIVATE PDP CONTEXT REJECT message, the MS shall stop timer T3380 and enter/remain in state PDP-INACTIVE.

If the ACTIVATE PDP CONTEXT REQUEST message was sent with request type set to "emergency" and the MS receives an ACTIVATE PDP CONTEXT REJECT message, then the MS may inform the upper layers of the failure to establish the emergency bearer.

NOTE 2: This can result in the upper layers requesting establishment of a CS emergency call (if not already attempted in the CS domain) or initiating other implementation specific mechanisms, e.g. procedures specified in 3GPP TS 24.229 [95] can result in the emergency call being attempted to another IP-CAN.

6.1.3.1.3.2 Handling of network rejection due to SM cause #26

If the SM cause value is #26 "insufficient resources" and the Back-off timer value IE is included, the MS shall ignore the Re-attempt indicator IE provided by the network, if any, and take different actions depending on the timer value received for timer T3396 in the Back-off timer value IE (if the MS is configured for dual priority, exceptions are specified in subclause 6.1.3.12; if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.11):

i) if the timer value indicates neither zero nor deactivated and an APN was included in the ACTIVATE PDP CONTEXT REQUEST message, the MS shall stop timer T3396 associated with the corresponding APN, if it is running. If the timer value indicates neither zero nor deactivated, the request type was different from "emergency", and no APN was included in the ACTIVATE PDP CONTEXT REQUEST message, the MS shall stop timer T3396 associated with no APN if it is running. The MS shall then start timer T3396 with the value provided in the Back-off timer value IE and:

The MS shall not stop timer T3396 upon a PLMN change or inter-system change;

ii) if the timer value indicates that this timer is deactivated, the MS:

– shall not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN that was sent by the MS, until the MS is switched off or the SIM/USIM is removed or the MS receives a REQUEST PDP CONTEXT ACTIVATION, REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message with the same APN from the network or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for the same APN from the network; and

– shall not send another ACTIVATE PDP CONTEXT REQUEST message without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without an APN sent by the MS, if the APN was not included in the ACTIVATE PDP CONTEXT REQUEST message and the request type was different from "emergency", until the MS is switched off or the SIM/USIM is removed or the MS receives for a non-emergency PDP context which was activated by the MS any of the following messages: a REQUEST PDP CONTEXT ACTIVATION without an APN, a REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS, or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a non-emergency PDN connection which was established without an APN sent by the MS.

The timer T3396 remains deactivated upon a PLMN change or inter-system change; and

iii) if the timer value indicates that this timer is zero, the MS:

– shall stop timer T3396 associated with the corresponding APN, if running, and may send an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for the same APN; and

– if the APN was not included in the ACTIVATE PDP CONTEXT REQUEST message and the request type was different from "emergency", the MS shall stop timer T3396 associated with no APN, if running, and may send an ACTIVATE PDP CONTEXT REQUEST message without an APN, or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS.

If the Back-off timer value IE is not included, then the MS may send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for the same APN.

The MS may initiate a PDP context activation procedure for emergency bearer services even if the timer T3396 is running.

If the timer T3396 is running when the MS enters state GMM-DEREGISTERED, the MS remains switched on, and the SIM/USIM in the MS remains the same, then timer T3396 is kept running until it expires or it is stopped.

If the MS is switched off when the timer T3396 is running, and if the SIM/USIM in the MS remains the same when the MS is switched on, the MS shall behave as follows:

– let t1 be the time remaining for T3396 timeout at switch off and let t be the time elapsed between switch off and switch on. If t1 is greater than t, then the timer shall be restarted with the value t1 – t. If t1 is equal to or less than t, then the timer need not be restarted. If the MS is not capable of determining t, then the MS shall restart the timer with the value t1; and

– if prior to switch off, timer T3396 was running because an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST, MODIFY PDP CONTEXT REQUEST or ACTIVATE MBMS CONTEXT REQUEST message containing the low priority indicator set to "MS is configured for NAS signalling low priority" was rejected with a timer value for timer T3396, and if timer T3396 is restarted at switch on, then the MS configured for dual priority shall handle session management requests as indicated in subclause 6.1.3.12.

6.1.3.1.3.3 Handling of network rejection due to SM cause other than SM cause #26

If the SM cause value is different from #26 "insufficient resources", #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed", #58 "PDP type non IP only allowed", #65 "maximum number of PDP contexts reached", and #66 "requested APN not supported in current RAT and PLMN combination", and the Back-off timer value IE is included, the MS shall take different actions depending on the timer value received in the Back-off timer value IE (if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.13):

i) if the timer value indicates neither zero nor deactivated, the MS shall start the back-off timer with the value provided in the Back-off timer value IE for the PDP context activation procedure and PLMN and APN combination and:

– shall not send another ACTIVATE PDP CONTEXT REQUEST message in the PLMN for the same APN that was sent by the MS, until the back-off timer expires, the MS is switched off or the SIM/USIM is removed; and

– shall not send another ACTIVATE PDP CONTEXT REQUEST message in the PLMN without an APN if the APN was not included in the ACTIVATE PDP CONTEXT REQUEST message, until the back-off timer expires, the MS is switched off or the SIM/USIM is removed;

ii) if the timer value indicates that this timer is deactivated, the MS:

– shall not send another ACTIVATE PDP CONTEXT REQUEST message in the PLMN for the same APN that was sent by the MS, until the MS is switched off or the SIM/USIM is removed; and

– shall not send another ACTIVATE PDP CONTEXT REQUEST message in the PLMN without an APN if the APN was not included in the ACTIVATE PDP CONTEXT REQUEST message, until the MS is switched off or the SIM/USIM is removed; and

iii) if the timer value indicates that this timer is zero, the MS:

– may send an ACTIVATE PDP CONTEXT REQUEST message in the PLMN for the same APN; and

– may send an ACTIVATE PDP CONTEXT REQUEST message in the PLMN without an APN if the APN was not included in the ACTIVATE PDP CONTEXT REQUEST message.

If the Back-off timer value IE is not included, then the MS shall ignore the Re-attempt indicator IE provided by the network, if any.

i) Additionally, if the SM cause value is #8 "operator determined barring", #27 "missing or unknown APN", #32 "service option not supported", or #33 "requested service option not subscribed", the MS shall proceed as follows:

– if the MS is registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), the MS shall behave as described above in the present subclause, using the configured SM_RetryWaitTime value as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], if available, as back-off timer value; and

– otherwise, if the MS is not registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), or if the SM_RetryWaitTime value is not configured, the MS shall behave as described above in the present subclause using the default value of 12 minutes for the back-off timer.

ii) For SM cause values different from #8 "operator determined barring", #27 "missing or unknown APN", #32 "service option not supported", or #33 "requested service option not subscribed", the MS behaviour regarding the start of a back-off timer is unspecified.

The MS shall not stop any back-off timer upon a PLMN change or inter-system change. If the network indicates that a back-off timer for the PDP context activation procedure and PLMN and APN combination is deactivated, then it remains deactivated upon a PLMN change or inter-system change.

NOTE 1: This means the back-off timer can still be running or be deactivated for the given SM procedure and PLMN and APN combination when the MS returns to the PLMN or when it performs inter-system change back from S1 mode to A/Gb or Iu mode. Thus the MS can still be prevented from sending another ACTIVATE PDP CONTEXT REQUEST message in the PLMN for the same APN.

If the back-off timer is started upon receipt of an ACTIVATE PDP CONTEXT REJECT message (i.e. the timer value was provided by the network, a configured value is available or the default value is used as explained above) or the back-off timer is deactivated, the MS behaves as follows:

i) after a PLMN change the MS may send an ACTIVATE PDP CONTEXT REQUEST message for the same APN in the new PLMN, if the back-off timer is not running and is not deactivated for the PDP context activation procedure and the combination of new PLMN and APN;

Furthermore as an implementation option, for the SM cause values #8 "operator determined barring", #27 "missing or unknown APN", #32 "service option not supported" or #33 "requested service option not subscribed", if the network does not include a Re-attempt indicator IE, the MS may decide not to automatically send another ACTIVATE PDP CONTEXT REQUEST message for the same APN, if the MS registered to a new PLMN which is in the list of equivalent PLMNs.

ii) if the network does not include the Re-attempt indicator IE to indicate whether re-attempt in S1 mode is allowed, or the MS ignores the Re-attempt indicator IE, e.g. because the Back-off timer value IE is not included, then:

– if the MS is registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), the MS shall apply the configured SM_RetryAtRATChange value as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], if available, to determine whether the MS may attempt a PDN connectivity procedure for the same PLMN and APN combination in S1 mode; and

– if the MS is not registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), or if the NAS configuration MO as specified in 3GPP TS 24.368 [135] is not available and the value for inter-system change is not configured in the USIM file NAS_CONFIG, then the MS behaviour regarding a PDN connectivity procedure for the same PLMN and APN combination in S1 mode is unspecified; and

iii) if the network includes the Re-attempt indicator IE indicating that re-attempt in an equivalent PLMN is not allowed, then depending on the timer value received in the Back-off timer value IE, for each combination of a PLMN from the equivalent PLMN list and the APN the MS shall start a back-off timer for the PDP context activation procedure with the value provided by the network, or deactivate the respective back-off timer as follows:

– If the Re-attempt indicator IE additionally indicates that re-attempt in S1 mode is allowed, the MS shall start or deactivate the back-off timer for A/Gb and Iu mode only; and

– otherwise the MS shall start or deactivate the back-off timer for A/Gb, Iu, and S1 mode.

If the back-off timer for a PLMN and APN combination was started or deactivated in S1 mode upon receipt of a PDN CONNECTIVITY REJECT message (see 3GPP TS 24.301 [120]) and the network indicated that re-attempt in A/Gb or Iu mode is allowed, then this back-off timer does not prevent the MS from sending an ACTIVATE PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode. If the network indicated that re-attempt in A/Gb or Iu mode is not allowed, the MS shall not send any ACTIVATE PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode until the back-off timer expires, the MS is switched off or the USIM is removed.

NOTE 2: The back-off timer is used to describe a logical model of the required MS behaviour. This model does not imply any specific implementation, e.g. as a timer or timestamp.

NOTE 3: Reference to back-off timer in this section can either refer to use of timer T3396 or to use of a different packet system specific timer within the MS. Whether the MS uses T3396 as a back-off timer or it uses different packet system specific timers as back-off timers is left up to MS implementation. This back-off timer is stopped when the MS is switched off or the SIM/USIM is removed.

The MS may initiate a PDP context activation procedure for emergency bearer services even if the back-off timer is running.

If the SM cause value is #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed" or #58 "PDP type non IP only allowed", the MS shall ignore the Back-off timer value IE provided by the network, if any. The MS shall not automatically send another ACTIVATE PDP CONTEXT REQUEST message for the same APN that was sent by the MS using the same PDP type, until any of the following conditions is fulfilled:

– the MS is registered to a new PLMN, and either the network did not include a Re-attempt indicator IE in the ACTIVATE PDP CONTEXT REJECT message or the Re-attempt indicator IE included in the message indicated that re-attempt in an equivalent PLMN is allowed;

– the MS is registered to a new PLMN which was not in the list of equivalent PLMNs at the time when the ACTIVATE PDP CONTEXT REJECT message was received;

– the PDP type which is used to access to the APN is changed;

– the MS is switched off; or

– the SIM/USIM is removed.

For the SM cause values #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed" and #58 "PDP type non IP only allowed", the MS shall ignore the value of the RATC bit in the Re-attempt indicator IE provided by the network, if any.

NOTE 4: For the SM cause values #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed" and #58 "PDP type non IP only allowed", re-attempt in S1 mode for the same APN (or no APN, if no APN was indicated by the MS) using the same PDP type is not allowed.

Furthermore as an implementation option, for the SM cause values #50 "PDP type IPv4 only allowed", #51 "PDP type IPv6 only allowed", #57 "PDP type IPv4v6 only allowed" and #58 "PDP type non IP only allowed", if the network does not include a Re-attempt indicator IE the MS may decide not to automatically send another ACTIVATE PDP CONTEXT REQUEST message for the same APN that was sent by the MS using the same PDP type, if the MS registered to a new PLMN which is in the list of equivalent PLMNs.

NOTE 5: Request to send another ACTIVATE PDP CONTEXT REQUEST message with a specific PDP type has to come from upper layers.

If the SM cause value is #65 "maximum number of PDP contexts reached", the MS shall determine the PLMN’s maximum number of PDP contexts in A/Gb or Iu mode (see subclause 6.1.3.0) as the number of active PDP contexts it has. The MS shall ignore the Back-off timer value IE and Re-attempt indicator IE provided by the network, if any.

NOTE 6: In some situations, when attempting to establish multiple PDP contexts, the number of active PDP contexts that the MS has when SM cause #65 is received is not equal to the maximum number of PDP contexts reached in the network.

NOTE 7: When the network supports emergency bearer services, it is not expected that SM cause #65 is returned by the network when the MS requests a PDP context for emergency bearer services.

The PLMN’s maximum number of PDP contexts in A/Gb or Iu mode applies to the PLMN in which the SM cause #65 "maximum number of PDP contexts reached" is received. When the MS is switched off or when the USIM is removed, the MS shall clear all previous determinations representing any PLMN’s maximum number of PDP contexts in A/Gb or Iu mode (see subclause 6.1.3.0). Upon successful registration with a new PLMN, the MS may clear previous determinations representing any PLMN’s maximum number of PDP contexts in A/Gb or Iu mode.

If the SM cause value is #66 "requested APN not supported in current RAT and PLMN combination", the MS shall take different actions depending on the Back-off timer value IE and the Re-attempt indicator IE optionally included:

i) If the Back-off timer value IE is not included, and either the Re-attempt indicator IE is not included or the Re-attempt indicator IE is included indicating that re-attempt in an equivalent PLMN is allowed, the MS shall not send an ACTIVATE PDP CONTEXT REQUEST message for the same APN in the current PLMN in A/Gb or Iu mode until the MS is switched off or the SIM/USIM is removed;

ii) if the Back-off timer value IE is not included, and the Re-attempt indicator IE is included and indicates that re-attempt in an equivalent PLMN is not allowed, the MS shall not send an ACTIVATE PDP CONTEXT REQUEST message for the same APN in any PLMN in the list of equivalent PLMNs in A/Gb or Iu mode until the MS is switched off or the SIM/USIM is removed; and

iii) if the Back-off timer value IE is included, the MS shall take different actions depending on the timer value received in the Back-off timer value IE:

a) if the timer value indicates neither zero nor deactivated, the MS shall start the back-off timer with the value provided in the Back-off timer value IE for the PLMN and APN combination and shall not send another ACTIVATE PDP CONTEXT REQUEST for the same APN in the current PLMN in A/Gb or Iu mode until the back-off timer expires, the MS is switched off or the SIM/USIM is removed;

b) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE PDP CONTEXT REQUEST message for the same APN in the current PLMN in A/Gb or Iu mode until the MS is switched off or the SIM/USIM is removed; and

c) if the timer value indicates that this timer is zero, the MS may send an ACTIVATE PDP CONTEXT REQUEST message in the PLMN for the same APN.

If the network includes the Re-attempt indicator IE indicating that re-attempt in an equivalent PLMN is not allowed, then

– for case a) the MS shall additionally start a back-off timer with the value provided in the Back-off timer value IE for the PDP context activation procedure for each combination of a PLMN from the equivalent PLMN list and the APN; and

– for case b) the MS shall deactivate the respective back-off timers for the PDP context activation procedure for each combination of a PLMN from the equivalent PLMN list and the APN.

For the SM cause value #66 "requested APN not supported in current RAT and PLMN combination" the MS shall ignore the value of the RATC bit in the Re-attempt indicator IE provided by the network, if any.

As an implementation option, for cases i), iii.a) and iii.b), if the Re-attempt indicator IE is not included, the MS may decide not to automatically send another ACTIVATE PDP CONTEXT REQUEST message for the same APN in a PLMN which is in the list of equivalent PLMNs.

6.1.3.1.3A Void

6.1.3.1.4 Unsuccessful PDP context activation requested by the network

Upon receipt of the REQUEST PDP CONTEXT ACTIVATION message, the MS may reject the network requested PDP context activation by sending the REQUEST PDP CONTEXT ACTIVATION REJECT message to the network. The message contains the same TI as included in the REQUEST PDP CONTEXT ACTIVATION and an additional cause code that typically indicates one of the following causes:

# 26: insufficient resources;

# 31: activation rejected, unspecified;

# 40: feature not supported; or

# 95 – 111: protocol errors.

The network shall stop timer T3385 and enter state PDP-INACTIVE.

6.1.3.1.5 Abnormal cases

The following abnormal cases can be identified:

a) Expiry of timers

In the mobile station:

On the first expiry of the timer T3380, the MS shall resend the ACTIVATE PDP CONTEXT REQUEST and shall reset and restart timer T3380. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3380, the MS shall release all resources possibly allocated for this invocation and shall abort the procedure; no automatic PDP context activation re-attempt shall be performed; and

– if the ACTIVATE PDP CONTEXT REQUEST message was sent with request type set to "emergency", then the MS may inform the upper layers of the failure to establish the emergency bearer.

NOTE: This can result in the upper layers requesting establishment of a CS emergency call (if not already attempted in the CS domain) or initiating other implementation specific mechanisms, e.g. procedures specified in 3GPP TS 24.229 [95] can result in the emergency call being attempted to another IP-CAN.

On the network side:

On the first expiry of the timer T3385, the network shall resend the message REQUEST PDP CONTEXT ACTIVATION and shall reset and restart timer T3385. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3385, the network shall release possibly allocated resources for this activation and shall abort the procedure.

b) Collision of MS initiated and network requested PDP context activation

If the MS uses dynamic PDP addressing that turns out to collide with the network requested PDP address, then there is no detection of collision specified but left for network implementation.

c) MS initiated PDP context activation request for an already activated PDP context (on the network side)

i) If the network receives a ACTIVATE PDP CONTEXT REQUEST message with the same combination of APN, PDP type and PDP address as an already activated PDP context, the network shall deactivate the existing PDP context and, if any, all the linked PDP contexts (matching the combination of APN, PDP type and PDP address), locally without notification to the MS and proceed with the requested PDP context activation.

ii) Alternatively (different combination of APN, PDP type and PDP address), if the NSAPI matches that of an already activated PDP context, then the network shall deactivate only the existing PDP context locally without notification to the MS and proceed with the requested PDP context activation.

It is an implementation option if the parameters used for comparison described in clause i) and ii) are the parameters provided in the (current and previous) ACTIVATE PDP CONTEXT REQUESTs or the parameters which are the result of the application of the selection rules defined in 3GPP TS 23.060 [74] Annex A.2.

The parameter provided in the current ACTIVATE PDP CONTEXT REQUEST can not be compared to the actually used parameters (result of application of selection rules defined in 3GPP TS 23.060 [74] Annex A.2) of the previously activated PDP contexts.

If the network receives an ACTIVATE PDP CONTEXT REQUEST message with request type "emergency" and there already is a PDN connection for emergency bearer services existing, the network shall reject the request with cause code #31 "activation rejected, unspecified".

d) Network initiated PDP context activation request for an already activated PDP context (on the mobile station side)

If the MS receives a REQUEST PDP CONTEXT ACTIVATION message with the same combination of APN, PDP type and PDP address as an already activated PDP context, the MS shall deactivate the existing PDP context and, if any, all the linked PDP contexts (matching the combination of APN, PDP type and PDP address) locally without notification to the network and proceed with the requested PDP context activation.

e) Additional MS initiated PDP context activation request received from an MS that is attached for emergency bearer services:

If the MS is attached for emergency bearer services the network shall only accept the PDP context activation request for emergency services. The network shall reject any other PDP context activation request with cause code #31 "activation rejected, unspecified".

f) Reception of the ACTIVATE PDP CONTEXT ACCEPT message and Bearer Control Mode violation

If the Selected Bearer Control Mode indicates other value than ‘MS only’ in the ACTIVATE PDP CONTEXT ACCEPT message although the protocol configuration options information element was not present or the MS Support of Network Requested Bearer Control indicator was not present in the protocol configuration options information element of the corresponding ACTIVATE PDP CONTEXT REQUEST message, the MS shall ignore the Selected Bearer Control Mode parameter received from the network and apply Bearer Control Mode ‘MS only’ for all active PDP contexts sharing the same PDP Address and APN.

Figure 6.3/3GPP TS 24.008: MS initiated PDP context activation procedure

Figure 6.4/3GPP TS 24.008: Network initiated PDP context activation procedure

6.1.3.1.6 Handling Activate PDP context request for MS configured for dual priority

If a PDP context exists that was created due to a request including a low priority indicator set to "MS is configured for NAS signalling low priority" and the upper layers of the MS request to activate a PDP context with the same APN and the low priority indicator set to "MS is not configured for NAS signalling low priority", when initiating the PDP context activation procedure, the MS shall:

– send an ACTIVATE PDP CONTEXT REQUEST message with the same combination of APN, PDP type and PDP address as the existing PDP context to activate a PDP context;

NOTE 1: This option relies on the network handling of abnormal cases as specified in subclause 6.1.3.1.5 case c).

– send an ACTIVATE PDP CONTEXT REQUEST message with the same combination of APN and PDP type as the existing PDP context but with a different PDP address, or without PDP address, to activate a PDP context; or

– send an ACTIVATE PDP CONTEXT REQUEST message with the same APN after the successful deactivation of the existing PDP context.

NOTE 2: The above list of options also apply for the case when the existing PDP context was created due to a request including a low priority indicator set to "MS is not configured for NAS signalling low priority" and the new request to activate a PDP context with the same APN contains a low priority indicator set to "MS is configured for NAS signalling low priority".

As an alternative the upper layers of the MS can request to activate a PDP context with a different APN.

6.1.3.2 Secondary PDP Context Activation Procedure

The purpose of this procedure is to establish an additional PDP context between the MS and the network for a specific Traffic Flow Template (TFT) and QoS profile on a specific NSAPI, when one or more PDP contexts has/have already been established for the particular PDP address and APN. The MS shall include a request for a TFT comprising at least one packet filter applicable for the uplink direction. Depending on the selected Bearer Control Mode being ‘MS only’ or ‘MS/NW’, the secondary PDP context activation procedure may either be initiated by the MS or by either the MS or the network, respectively. However, the network and the MS shall not initiate a secondary PDP context activation procedure for established PDP context of "non IP" PDP type.

The network shall allocate packet filter identifiers and manage packet filter evaluation precedence for the packet filters added by the network. The MS shall allocate packet filter identifiers and manage packet filter evaluation precedence for the packet filters added by the MS.

If there is a PDN connection for emergency bearer services established, the MS shall not initiate a secondary PDP context activation procedure for this connection unless triggered by the network.

NOTE: 3GPP TS 23.060 [74] subclause 9.3 specifies that a packet filter applicable for the downlink direction is not mandatory in a TFT.

6.1.3.2.1 Successful Secondary PDP Context Activation Procedure Initiated by the MS

In order to request a PDP context activation with the same PDP address and APN as an already active PDP context, the MS shall send an ACTIVATE SECONDARY PDP CONTEXT REQUEST message to the network, enter the state PDP-ACTIVE-PENDING and start timer T3380. The message shall contain the selected NSAPI. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. The message shall also include a QoS profile, a requested LLC SAPI and the Linked TI. The QoS profile is the requested QoS. If present, the TFT shall be sent transparently through the SGSN to the GGSN to enable packet classification and policing for downlink data transfer. If the selected Bearer Control Mode is ‘MS/NW’ and a TFT IE is included in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message, the MS shall set the packet filter direction parameter of each packet filter in the TFT to a value different from "00". The MS shall allocate packet filter identifiers for all packet filters included in the TFT.

Upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REQUEST, the network shall validate the message by verifying the TI given in the Linked TI IE to be any of the active PDP context(s). The same GGSN address shall be used by the SGSN as for the already established PDP context(s) for that PDP address. The network shall select a radio priority level based on the QoS negotiated and shall reply with an ACTIVATE SECONDARY PDP CONTEXT ACCEPT message, if the request can be accepted.

NOTE 1: If the MS requested a value for a QoS parameter that is not within the range specified by 3GPP TS 23.107 [81], the network should negotiate the parameter to a value that lies within the specified range.

Upon receipt of the message ACTIVATE SECONDARY PDP CONTEXT ACCEPT, the MS shall stop timer T3380 and enter the state PDP-ACTIVE. If the offered QoS parameters received from the network differ from the QoS requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP context deactivation procedure.

In A/Gb mode the MS shall initiate establishment of the logical link for the LLC SAPI indicated by the network with the offered QoS and selected radio priority level if no logical link has been already established for that SAPI. If the LLC SAPI indicated by the network can not be supported by the MS, the MS shall initiate the PDP context deactivation procedure.

In Iu mode, both SGSN and MS shall store the LLC SAPI and the radio priority in the PDP context. If an Iu mode to A/Gb mode Routing Area Update is performed, the new SGSN shall initiate establishment of the logical link using the negotiated LLC SAPI, the negotiated QoS profile and selected radio priority level stored in the PDP context as in an A/Gb mode to A/Gb mode Routing Area Update.

NOTE 2: The radio priority level and the LLC SAPI parameters, though not used in Iu mode, shall be included in the messages, in order to support handover between Iu mode and A/Gb mode networks.

At inter-system change from Iu mode to A/Gb mode, SM shall locally deactivate the active PDP context(s) if SM does not have the following parameters:

– LLC SAPI; and

– radio priority.

6.1.3.2.1a Successful Secondary PDP Context Activation Procedure Requested by the network

In order to request a PDP context activation with the same PDP address and APN as an already active PDP context, the network shall send a REQUEST SECONDARY PDP CONTEXT ACTIVATION message to the MS and start timer T3385. The message contains the required QoS, Linked TI, and optionally protocol configuration options and a TFT. The network shall always include a TFT in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message. If present, the TFT shall be sent transparently through the SGSN to the MS to enable packet classification and policing for uplink and downlink data transfer. The network shall allocate packet filter identifiers for all packet filters included in the TFT.

NOTE: A network implementing an earlier release of this specification can send a REQUEST SECONDARY PDP CONTEXT ACTIVATION message without any TFT.

Upon receipt of a REQUEST SECONDARY PDP CONTEXT ACTIVATION message, if the MS sent an APN for the establishment of the PDN connection, the MS shall stop the timer T3396 if it is running for the APN sent by the MS. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop the timer T3396 associated with no APN if it is running. If the REQUEST SECONDARY PDP CONTEXT ACTIVATION message was received for an emergency PDN connection, the UE shall not stop the timer T3396 associated with no APN if it is running. For any case, the MS shall then either initiate the secondary PDP context activation procedure as described in the subclause 6.1.3.2.1 or shall reject the activation request by sending a REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message as described in subclause 6.1.3.2.2a. The value of the reject cause IE of the REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message shall indicate the reason for rejection, e.g. "insufficient resources to activate another context".

The MS shall maintain the previously negotiated Bearer Control Mode (BCM) for all active PDP contexts sharing the same PDP Address and APN and ignore any BCM parameter, if included in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message. If the previously negotiated BCM is ‘MS only’, the MS should reject the PDP context activation (see subclause 6.1.3.2.2a).

The ACTIVATE SECONDARY PDP CONTEXT REQUEST message sent by the MS in order to initiate the secondary PDP context activation procedure shall contain the QoS and Linked TI required in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message. The MS shall also include a TFT with packet filters as specified in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message.

Upon receipt of the ACTIVATE SECONDARY PDP CONTEXT REQUEST message, the network shall stop timer T3385.

The same procedures then apply as described for MS initiated secondary PDP context activation.

6.1.3.2.2 Unsuccessful Secondary PDP Context Activation Procedure initiated by the MS

6.1.3.2.2.1 General

Upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REQUEST message, the network may reject the MS initiated PDP context activation by sending an ACTIVATE SECONDARY PDP CONTEXT REJECT message to the MS. The message shall contain a cause code that typically indicates one of the following:

# 26: insufficient resources;

# 30: activation rejected by GGSN, Serving GW or PDN GW;

# 31: activation rejected, unspecified;

# 32: service option not supported;

# 33: requested service option not subscribed;

# 34: service option temporarily out of order;

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 43: unknown PDP context;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);

# 46: PDP context without TFT already activated;

# 48: request rejected, Bearer Control Mode violation;

# 56: collision with network initiated request;

# 60: bearer handling not supported;

# 65: maximum number of PDP contexts reached; or

# 95 – 111: protocol errors.

The network may include a Back-off timer value IE in the ACTIVATE SECONDARY PDP CONTEXT REJECT message.

If the Back-off timer value IE is included and the SM cause value is different from #26 "insufficient resources" and #65 "maximum number of PDP contexts reached", the network may include the Re-attempt indicator IE to indicate whether the MS is allowed to attempt a bearer resource allocation procedure in the PLMN for the same APN in S1 mode, and whether another attempt in A/Gb and Iu mode or in S1 mode is allowed in an equivalent PLMN.

If the ACTIVATE SECONDARY PDP CONTEXT REQUEST message is related to an already active LIPA PDN connection or SIPTO at the local network PDN connection, then the network shall reply with an ACTIVATE SECONDARY PDP CONTEXT REJECT message with cause code #60 "bearer handling not supported".

If a PDP context for the TI given in the Linked TI IE exists, then the TFT in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message is checked by the network for different types of TFT IE errors as specified in subclause 6.1.3.2.3.

Upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REJECT message, the MS shall stop timer T3380 and enter the state PDP-INACTIVE.

6.1.3.2.2.2 Handling of network rejection due to SM cause #26

i) if the timer value indicates neither zero nor deactivated, the MS shall stop timer T3396 associated with the corresponding APN, if it is running. The MS shall then start timer T3396 with the value provided in the Back-off timer value IE and not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN until timer T3396 expires or timer T3396 is stopped. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop timer T3396 associated with no APN, if it is running. The MS shall then start timer T3396 with the value provided in the Back-off timer value IE and not send another ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without an APN sent by the MS, until timer T3396 expires or timer T3396 is stopped. The MS shall not stop timer T3396 upon a PLMN change or inter-system change;

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN until the MS is switched off or the SIM/USIM is removed or the MS receives a REQUEST PDP CONTEXT ACTIVATION, REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for the same APN or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for the same APN from the network. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall not send another ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without an APN sent by the MS, until the MS is switched off or the SIM/USIM is removed or the MS receives any of the following messages: a REQUEST PDP CONTEXT ACTIVATION without an APN, a REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS, or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for a non-emergency PDN connection established without an APN sent by the MS. The timer T3396 remains deactivated upon a PLMN change or inter-system change; or

iii) if the timer value indicates that this timer is zero, the MS:

– if the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop timer T3396 associated with no APN, if running, and may send an ACTIVATE PDP CONTEXT REQUEST message without an APN, or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS.

If the Back-off timer value IE is not included, the MS may send an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for the same APN.

If the MS is switched off when the timer T3396 is running, and if the SIM/USIM in the MS remains the same when the MS is switched on, the MS behaves as follows:

6.1.3.2.2.3 Handling of network rejection due to SM cause other than SM cause #26

If the SM cause value is different from #26 "insufficient resources" and #65 "maximum number of PDP contexts reached", and the Back-off timer value IE is included, the MS takes different actions depending on the timer value received in the Back-off timer value IE (if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.13):

i) if the timer value indicates neither zero nor deactivated, the MS shall start the back-off timer with the value provided in the Back-off timer value IE for the secondary PDP context activation procedure and PLMN and APN combination and not send another ACTIVATE SECONDARY PDP CONTEXT REQUEST message in the PLMN for the same APN until the back-off timer expires, the MS is switched off or the SIM/USIM is removed;

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE SECONDARY PDP CONTEXT REQUEST message in the PLMN for the same APN until the MS is switched off or the SIM/USIM is removed; and

iii) if the timer value indicates that this timer is zero, the MS may send an ACTIVATE SECONDARY PDP CONTEXT REQUEST message in the PLMN for the same APN.

If the Back-off timer value IE is not included, then the MS shall ignore the Re-attempt indicator IE provided by the network, if any.

i) Additionally, if the SM cause value is #32 "service option not supported", or #33 "requested service option not subscribed", the MS shall proceed as follows:

ii) For SM cause values different from #32 "service option not supported", or #33 "requested service option not subscribed", the MS behaviour regarding the start of a back-off timer is unspecified.

The MS shall not stop any back-off timer upon a PLMN change or inter-system change. If the network indicates that a back-off timer for the secondary PDP context activation procedure and PLMN and APN combination is deactivated, then it remains deactivated upon a PLMN change or inter-system change.

NOTE 1: This means the back-off timer can still be running or be deactivated for the given SM procedure and PLMN and APN combination when the MS returns to the PLMN or when it performs inter-system change back from S1 mode to A/Gb or Iu mode. Thus the MS can still be prevented from sending another ACTIVATE SECONDARY PDP CONTEXT REQUEST message in the PLMN for the same APN.

If the back-off timer is started upon receipt of an ACTIVATE SECONDARY PDP CONTEXT REJECT message (i.e. the timer value was provided by the network, a configured value is available or the default value is used as explained above) or the back-off timer is deactivated, the MS behaves as follows:

i) after a PLMN change the MS may send an ACTIVATE SECONDARY PDP CONTEXT REQUEST message for the same APN in the new PLMN, if the back-off timer is not running and is not deactivated for the secondary PDP context activation procedure and the combination of new PLMN and APN;

Furthermore as an implementation option, for the SM cause values #32 "service option not supported" or #33 "requested service option not subscribed", if the network does not include a Re-attempt indicator IE, the MS may decide not to automatically send another ACTIVATE SECONDARY PDP CONTEXT REQUEST message for the same APN, if the MS registered to a new PLMN which is in the list of equivalent PLMNs.

– if the MS is registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), the MS shall apply the configured SM_RetryAtRATChange value as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], if available, to determine whether the MS may attempt a bearer resource allocation procedure for the same PLMN and APN combination in S1 mode; and

– if the MS is not registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), or if the NAS configuration MO as specified in 3GPP TS 24.368 [135] is not available and the value for inter-system change is not configured in the USIM file NAS_CONFIG, then the MS behaviour regarding a bearer resource allocation procedure for the same PLMN and APN combination in S1 mode is unspecified; and

iii) if the network includes the Re-attempt indicator IE indicating that re-attempt in an equivalent PLMN is not allowed, then depending on the timer value received in the Back-off timer value IE, for each combination of a PLMN from the equivalent PLMN list and the APN the MS shall start a back-off timer for the secondary PDP context activation procedure with the value provided by the network, or deactivate the respective back-off timer as follows:

– If the Re-attempt indicator IE additionally indicates that re-attempt in S1 mode is allowed, the MS shall start or deactivate the back-off timer for A/Gb and Iu mode only; and

– otherwise the MS shall start or deactivate the back-off timer for A/Gb, Iu, and S1 mode.

If the back-off timer for a PLMN and APN combination was started or deactivated in S1 mode upon receipt of a BEARER RESOURCE ALLOCATION REJECT message (see 3GPP TS 24.301 [120]) and the network indicated that re-attempt in A/Gb or Iu mode is allowed, then this back-off timer does not prevent the MS from sending an ACTIVATE SECONDARY PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode. If the network indicated that re-attempt in A/Gb or Iu mode is not allowed, the MS shall not send any ACTIVATE SECONDARY PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode, until the timer expires, the MS is switched off or the USIM is removed.

NOTE 2: The back-off timer is used to describe a logical model of the required MS behaviour. This model does not imply any specific implementation, e.g. as a timer or timestamp.

NOTE 4: In some situations, when attempting to establish multiple PDP contexts, the number of active PDP contexts that the MS has when cause #65 is received is not equal to the maximum number of PDP contexts reached in the network.

The PLMN’s maximum number of PDP context in A/Gb or Iu mode applies to the PLMN in which the SM cause #65 "maximum number of PDP contexts reached" is received. When the MS is switched off or when the USIM is removed, the MS shall clear all previous determinations representing any PLMN’s maximum number of PDP contexts in A/Gb or Iu mode (see subclause 6.1.3.0). Upon successful registration with a new PLMN, the MS may clear previous determinations representing any PLMN’s maximum number of PDP contexts in A/Gb or Iu mode.

6.1.3.2.2a Unsuccessful secondary PDP context activation requested by the network

Upon receipt of the REQUEST SECONDARY PDP CONTEXT ACTIVATION message, the MS may reject the network requested secondary PDP context activation by sending the REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message to the network. The message contains the same TI as included in the REQUEST SECONDARY PDP CONTEXT ACTIVATION and an additional cause code that typically indicates one of the following causes:

# 26: insufficient resources;

# 31: activation rejected, unspecified;

# 40: feature not supported;

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 43: unknown PDP context;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);

# 46: PDP context without TFT already activated;

# 48: request rejected, Bearer Control Mode violation; or

# 95 – 111: protocol errors.

The MS should reply with the REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message with cause #48 "request rejected, Bearer Control Mode violation" if the previously negotiated Bearer Control Mode is ‘MS-only’.

If a PDP context for the TI given in the Linked TI IE exists, then the TFT in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message is checked by the MS for different types of TFT IE errors as specified in subclause 6.1.3.2.3.

Upon receipt of a REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message, the network shall stop timer T3385 and enter state PDP-INACTIVE.

6.1.3.2.3 Abnormal cases

The following abnormal cases can be identified:

a) Expiry of timers

In the mobile station:

On the first expiry of the timer T3380, the MS shall resend the ACTIVATE SECONDARY PDP CONTEXT REQUEST and shall reset and restart timer T3380. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3380, the MS shall release all resources possibly allocated for this invocation and shall abort the procedure; no automatic PDP context activation re-attempt shall be performed.

On the network side:

On the first expiry of the timer T3385, the network shall resend the message REQUEST SECONDARY PDP CONTEXT ACTIVATION and shall reset and restart timer T3385. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3385, the network shall release possibly allocated resources for this activation and shall abort the procedure.

b) MS initiated secondary PDP context activation procedure for an already activated PDP context (On the network side)

If the NSAPI matches that of an already activated PDP context, the network shall deactivate the existing PDP context locally without notification to the MS and proceed with the requested PDP context activation. The case of a TI match is described in subclause 8.3.2.

c) no PDP context with linked TI activated (on the network side)

The network shall then check whether there is an activated PDP context for the TI given in the Linked TI IE in the ACTIVATE SECONDARY PDP CONTEXT REQUEST message. If there is no active PDP context for the specified TI, the network shall reply with an ACTIVATE SECONDARY PDP CONTEXT REJECT message, cause code indicating "unknown PDP context".

d) no PDP context with Linked TI activated (on the mobile station side)

The MS shall check whether there is an activated PDP context for the TI given in the Linked TI IE in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message. If there is no active PDP context for the specified TI, the MS shall reply with a REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message, cause code indicating "unknown PDP context".

e) MS initiated secondary PDP context activation procedure for a PDN connection established for emergency bearer services (on the network side)

If the MS initiated secondary PDP context activation procedure is for a PDN connection established for emergency bearer services the network shall reply with an ACTIVATE SECONDARY PDP CONTEXT REJECT message, cause code indicating "activation rejected, unspecified".

f) no TFT IE is received in the REQUEST SECONDARY PDP CONTEXT ACTIVATION message (on the mobile station side)

The MS shall either:

A) reply with a REQUEST SECONDARY PDP CONTEXT ACTIVATION REJECT message, cause code indicating "semantic error in the TFT operation"; or

B) optionally, to support networks compliant with earlier versions of the protocol, accept the network requested secondary PDP context activation and proceed as specified in subclause 6.1.3.2.1a. If another PDP context with the same PDP address and APN without a TFT exists, the MS shall deactivate this old PDP context without a TFT by explicit peer-to-peer signalling between the MS and the network.

If during a previous inter-system change from S1 mode to A/Gb or Iu mode the default PDP context linked to the new PDP context was mapped from an EPS bearer context, the MS shall follow option A.

NOTE 1: A network implementing this version of the protocol will always include a request for a TFT when requesting the activation of a non-default PDP context.

If a PDP context for the TI given in the Linked TI IE exists, then the TFT in the ACTIVATE SECONDARY PDP CONTEXT REQUEST or the REQUEST SECONDARY PDP CONTEXT ACTIVATION message is checked for different types of TFT IE errors as follows:

a) Semantic errors in TFT operations:

1) When the TFT operation is an operation other than "Create a new TFT".

The network shall reject the activation request with cause "semantic error in the TFT operation".

The MS shall reject the activation request with cause "semantic error in the TFT operation".

b) Syntactical errors in TFT operations:

1) When the TFT operation is "Create a new TFT" and the packet filter list in the TFT IE is empty.

2) Void.

3) When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

The network shall reject the activation request with cause "syntactical error in the TFT operation".

The MS shall reject the activation request with cause "syntactical error in the TFT operation".

c) Semantic errors in packet filters:

1) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the network determines a semantic error in a packet filter is outside the scope of the present document.

2) When the resulting TFT does not contain any packet filter applicable for the uplink direction.

NOTE 2: When BCM=’MS only’, the MS is allowed to include a TFT with packet filters without any explicit direction information, i.e. with value "00", and such packet filters are applicable for both uplink and downlink directions.

The network shall reject the activation request with cause "semantic errors in packet filter(s)".

The MS shall reject the activation request with cause "semantic errors in packet filter(s)".

d) Syntactical errors in packet filters:

1) When the TFT operation is "Create a new TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers.

2) When the TFT operation is "Create a new TFT" and two or more packet filters in all TFTs associated with this PDP address and APN would have identical packet filter precedence values.

3) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

In case 2) the network shall not diagnose an error, further process the new activation request and, if it was processed successfully, delete the old packet filters which have identical filter precedence values. Furthermore, by means of explicit peer-to-peer signalling between the MS and the network, the network shall deactivate the PDP context(s) for which it has deleted the packet filters.

In cases 1) and 3) the network shall reject the activation request with cause "syntactical errors in packet filter(s)".

In case 2) the MS shall not diagnose an error, further process the new activation request and, if it was processed successfully, delete the old packet filters which have identical filter precedence values. Furthermore, by means of explicit peer-to-peer signalling between the network and the MS, the MS shall deactivate the PDP context(s) for which it has deleted the packet filters.

In cases 1) and 3) the MS shall reject the activation request with cause "syntactical errors in packet filter(s)".

Otherwise, the network shall accept the activation request by replying to the MS with an ACTIVATE SECONDARY PDP CONTEXT ACCEPT message. In case of network requested secondary PDP context activation procedure the MS shall accept the activation request by replying to the network with an ACTIVATE SECONDARY PDP CONTEXT REQUEST message.

Figure 6.5/3GPP TS 24.008: MS initiated secondary PDP context activation procedure

Figure 6.5a/3GPP TS 24.008: Network requested secondary PDP context activation procedure

6.1.3.3 PDP context modification procedure

The PDP context modification procedure is invoked by the network or by the MS, in order to:

– inform about the change of the 3GPP PS data off UE status for a PDN connection;

– change the QoS negotiated;

– change the Radio priority level; or

– change the TFT,

negotiated during the PDP context activation procedure, the secondary PDP context activation procedure or at previously performed PDP context modification procedures. Depending on the selected Bearer Control Mode being ‘MS only’ or ‘MS/NW’, the MS or the network respectively may also create and delete a TFT of an active default PDP context. The PDP context modification procedure can be initiated by the network or the MS at any time when a PDP context is active. The network and the MS shall manage packet filter identifiers for the packet filters each modifies or deletes. The network and the MS shall manage packet filter evaluation precedence for the packet filters each modifies.If the MS changes a TFT, which is not assigned to a default PDP context, the MS shall ensure that at least one packet filter applicable for the uplink direction remains among the packet filters created by the MS in that TFT, or no own packet filters . If the network changes a TFT, which is not ass igned to a default PDP context, the network shall ensure that at least one packet filter applicable for the uplink direction remains among the TFT packet filters created by the network in that TFT, or no own packet filters. The MS supporting S1 mode shall not modify the QoS of the first PDP context that was established within the PDN connection. The MS not supporting S1 mode should not modify the QoS of the first PDP context that was established within the PDN connection (see 3GPP TS 23.060 [74]).

To indicate a change of 3GPP PS data off UE status for a PDN connection, the MS shall include the protocol configuration options IE in the MODIFY PDP CONTEXT REQUEST message and set the 3GPP PS data off UE status only if the network included the 3GPP PS data off support indication for the PDN connection established by the PDP context activation procedure. The MS behaves as described in subclause 4.7.1.10.

When the PDP context modification procedure is used to indicate a change of 3GPP PS data off UE status for a PDN connection (see subclause 4.7.1.10), the UE shall initiate the PDP context modification procedure even if the timer T3396 or the back-off timer is running or is deactivated.

The PDP context modification procedure may also be invoked by the MS, in order to upgrade the maximum bit rate and to trigger the re-establishment of the radio access bearer for an activated PDP context which is preserved in the MS with maximum bit rate values of 0kbit/s for both uplink and downlink (see 3GPP TS 23.060 [74]).

NOTE 1: As described in 3GPP TS 23.060 [74], the MS only preserves PDP contexts with a TFT including packet filter(s) set by the MS.

– the PDP Context Modification request is accepted by the network but the radio access bearer is not established; or

– the PDP Context Modification request is rejected with cause "insufficient resources" (see subclause 6.1.3.3.3),

then the MS is not required to start a new PDP Context Modification procedure or to start a Service Request procedure in order to trigger the re-establishment of the radio access bearer.

If there is a PDN connection for emergency bearer services established, the MS shall not request a modification of bearer resources for this PDN connection.

The network requested PDP context modification procedure may also be used to update the PDP address when external PDP address allocation is performed, in which case the MS receives the PDP address in the MODIFY PDP CONTEXT REQUEST (Network to MS direction) message.

NOTE 2: The procedure may be initiated by the network due to an inter-SGSN Routing Area Updating when a PDP context is active.

The network requested PDP context modification procedure may also be used to update the WLAN offload indication, in which case the MS receives the updated WLAN offload indication in the MODIFY PDP CONTEXT REQUEST (Network to MS direction) message.

6.1.3.3.1 Network initiated PDP Context Modification

In order to initiate the procedure, the network sends the MODIFY PDP CONTEXT REQUEST message to the MS and starts timer T3386. The message shall contain the new QoS and the radio priority level and LLC SAPI that shall be used by the MS in A/Gb mode at the lower layers for the transmission of data related to the PDP context. The MODIFY PDP CONTEXT REQUEST message may also contain packet filters in the TFT information element. If the selected Bearer Control Mode is ‘MS/NW’ and the TFT information element is included in the MODIFY PDP CONTEXT REQUEST message, the network shall include packet filter(s), or if no packet filters are proposed to be either added, replaced or deleted, it shall set TFT operation code to "No TFT operation" and include packet filter identifier(s) in the Packet filter identifier parameter in the parameters list to indicate which packet filter(s) in the TFT is associated with the QoS change. If the TFT information element is included in the MODIFY PDP CONTEXT REQUEST message and packet filter(s) is proposed to be added, the network shall allocate packet filter identifier(s) for all packet filters to be added to the TFT. The network shall allocate packet filter identifier value s which are currently not allocated to any existing packet filter of the same TFT.

The network informs the MS about the Bearer Control Mode to be applied for all active PDP contexts sharing the same PDP Address and APN by including the selected Bearer Control Mode parameter in the protocol configuration options information element. This information is either explicitly given in the MODIFY PDP CONTEXT REQUEST message or implicitly given by not being present. The MS shall act according to the presence of the protocol configuration options information element and the value of the selected Bearer Control Mode parameter in the MODIFY PDP CONTEXT REQUEST message:

– if the protocol configuration options information element is not present, the MS shall apply Bearer Control Mode ‘MS only’ for all active PDP contexts sharing the same PDP Address and APN.

– if the selected Bearer Control Mode parameter is not present in the protocol configuration options information element, the MS shall apply Bearer Control Mode ‘MS only’ for all active PDP contexts sharing the same PDP Address and APN.

– if the selected Bearer Control Mode parameter is present in the protocol configuration options information element, the MS shall apply Bearer Control Mode according to the value of this parameter for all active PDP contexts sharing the same PDP Address and APN.

If a WLAN offload indication information element is included in the MODIFY PDP CONTEXT REQUEST message, the MS shall replace stored WLAN offload acceptability values for this PDN connection with the newly received offload indications and use the UTRAN offload acceptability value to determine whether this PDN connection is offloadable to WLAN or not.

Upon receipt of the MODIFY PDP CONTEXT REQUEST message, if the MS sent an APN for the establishment of the PDN connection, the MS shall stop the timer T3396 if it is running for the APN sent by the MS.If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop the timer T3396 associated with no APN if it is running. If the MODIFY PDP CONTEXT REQUEST message was received for an emergency PDN connection, the MS shall not stop the timer T3396 associated with no APN if it is running. For any case, the MS shall then reply with the MODIFY PDP CONTEXT ACCEPT message, if the MS accepts the new QoS and the indicated LLC SAPI.

The network shall upon receipt of the MODIFY PDP CONTEXT ACCEPT message stop timer T3386.

In A/Gb mode, the network shall establish, reconfigure or continue using the logical link with the new QoS for the LLC SAPI indicated in the MODIFY PDP CONTEXT REQUEST message.

In Iu mode, if the Radio Access Bearer supporting the PDP context is active, then the network shall reconfigure and continue using the Radio Access Bearer with the new QoS indicated in the MODIFY PDP CONTEXT REQUEST message; if the PDP context is preserved, then the network may re-establish a Radio Access Bearer with the new QoS indicated in the MODIFY PDP CONTEXT REQUEST message.

6.1.3.3.2 MS initiated PDP Context Modification accepted by the network

In order to initiate the procedure, the MS sends the MODIFY PDP CONTEXT REQUEST message to the network, enters the state PDP-MODIFY-PENDING and starts timer T3381. The message may contain the requested new QoS and/or the TFT and the requested LLC SAPI (used in A/Gb mode). If the selected Bearer Control Mode is ‘MS/NW’ and the MS wants to modify the QoS, it shall include a TFT with packet filter(s), or if no packet filters are proposed to be either added, replaced or deleted, it shall set TFT operation code to "No TFT operation" and include packet filter identifier(s) in the Packet filter identifier parameter in the parameters list to indicate which packet filter(s) in the TFT is associated with the QoS change. If the TFT information element is included in the MODIFY PDP CONTEXT REQUEST message and packet filters are proposed to be added, the MS shall allocate packet filter identifier(s) for all packet filters to be added to the TFT. The MS shall allocate packet filter identifier value s which are currently not allocated to any existing packet filter of the TFT. If a PDP context is associated with a TFT containing packet filters established by both the MS and the network, the only parameters in the QoS profile of that PDP context the MS is allowed to modify are the bitrate parameters.

Upon receipt of the MODIFY PDP CONTEXT REQUEST message, the network may reply with the MODIFY PDP CONTEXT ACCEPT message in order to accept the context modification. The reply message may contain the negotiated QoS and the radio priority level based on the new QoS profile and the negotiated LLC SAPI that shall be used in A/Gb mode by the logical link.

Upon receipt of the MODIFY PDP CONTEXT ACCEPT message, the MS shall stop the timer T3381. If the offered QoS parameters received from the network differs from the QoS requested by the MS, the MS shall either accept the negotiated QoS or initiate the PDP context deactivation procedure.

If a modification of QoS is requested by the MS, which the network can not accept, being unable to provide the requested QoS, it should maintain the QoS negotiated as previously negotiated or propose a new QoS. That means that the network should not reject the MS initiated PDP context modification request due to the unavailability of the QoS. If the MS requested a value for a QoS parameter that is not within the range specified by 3GPP TS 23.107[81], the network should negotiate the parameter to a value that lies within the specified range.

6.1.3.3.3 MS initiated PDP Context Modification not accepted by the network

6.1.3.3.3.1 General

Upon receipt of a MODIFY PDP CONTEXT REQUEST message, the network may reject the MS initiated PDP context modification request by sending a MODIFY PDP CONTEXT REJECT message to the MS. The message shall contain a cause code that typically indicates one of the following:

# 26: insufficient resources;

# 30: activation rejected by GGSN, Serving GW or PDN GW;

# 32: Service option not supported;

# 37: QoS not accepted;

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);

# 48: request rejected, Bearer Control Mode violation;

# 60: bearer handling not supported; or

# 95 – 111: protocol errors.

If upon the reception of a MODIFY PDP CONTEXT REQUEST message the network fails to re-establish the radio access bearer for a PDP context whose maximum bit rate in uplink and downlink is set to 0kbit/s, the network shall reply with a MODIFY PDP CONTEXT REJECT message with cause #26 "insufficient resources".

If a TFT modification was requested and the requested TFT is not available, then the MODIFY PDP CONTEXT REJECT message shall be sent.

The network shall reply with a MODIFY PDP CONTEXT REJECT message with cause #48 "request rejected, Bearer Control Mode violation", if

– the selected Bearer Control Mode is ‘MS/NW’ and the MS requests to create a TFT for a PDP context that was established without TFT;

– the selected Bearer Control Mode is ‘MS/NW’ and the MS requests to upgrade the QoS of a PDP context without downlink packet filters, unless uplink packet filters already exist for the PDP context and the MS requests with the same MODIFY PDP CONTEXT REQUEST message to create downlink packet filters ;

– the selected Bearer Control Mode is ‘MS/NW’ and the MS requests to modify the QoS, but does not include a TFT with at least apacket filter identifiers to indicate which packet filters in the TFT that is associated with the QoS change; or

– the selected Bearer Control Mode is ‘MS/NW’ and the MS requests to modify the QoS for a PDP context associated with a TFT containing packet filters established by both the MS and the network and the MS tries to modify other parameters than the bitrate parameters in the QoS profile of that PDP context.

If a TFT modification was requested and the MS requests to modify or delete packet filters which were added by the network, then the MODIFY PDP CONTEXT REJECT message shall be sent.

If the MS has requested to modify the QoS of a default PDP context, the network shall reply with a MODIFY PDP CONTEXT REJECT message with cause code "QoS not accepted".

If the MS has requested to modify the PDP context of a LIPA PDN connection or SIPTO at the local network PDN connection, then the network shall reply with a MODIFY PDP CONTEXT REJECT message with cause code "bearer handling not supported".

The TFT in the request message is checked by the network for different types of TFT IE errors as specified in subclause 6.1.3.3.4.

The network may include a Back-off timer value IE in the MODIFY PDP CONTEXT REJECT message.

The network shall not include the SM cause value #26 "insufficient resources" in the MODIFY PDP CONTEXT REJECT message due to APN based congestion control being active.

If the Back-off timer value IE is included and the SM cause value is not #26 "insufficient resources", the network may include the Re-attempt indicator IE to indicate whether the MS is allowed to attempt a bearer resource modification procedure in the PLMN for the same APN in S1 mode, and whether another attempt in A/Gb and Iu mode or in S1 mode is allowed in an equivalent PLMN.

Upon receipt of a MODIFY PDP CONTEXT REJECT message, the MS shall stop timer T3381 and enter the state PDP-ACTIVE.

6.1.3.3.3.2 Handling of network rejection due to SM cause #26

If the SM cause value is #26 and the Back-off timer value IE is included, the MS shall ignore the Re-attempt indicator IE provided by the network, if any, and take different actions depending on the timer value received for timer T3396 in the Back-off timer value IE (if the MS is configured for dual priority, exceptions are specified in subclause 6.1.3.12; if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.11):

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN until the MS is switched off or the SIM/USIM is removed or the MS receives REQUEST PDP CONTEXT ACTIVATION, REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for the same APN or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for the same APN from the network. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall not send another ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without APN sent by the MS, until the MS is switched off or the SIM/USIM is removed or the MS receives any of the following messages: a REQUEST PDP CONTEXT ACTIVATION without an APN, a REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS, or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for a non-emergency PDN connection established without an APN sent by the MS. The timer T3396 remains deactivated upon a PLMN change or inter-system change; or

iii) if the timer value indicates that this timer is zero, the MS:

If the Back-off timer value IE is not included, the MS may send an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for the same APN.

If the MS is switched off when the timer T3396 is running, and if the SIM/USIM in the MS remains the same when the MS is switched on, the MS behaves as follows:

6.1.3.3.3.3 Handling of network rejection due to SM cause other than SM cause #26

If the SM cause value is not #26 "insufficient resources" and the Back-off timer value IE is included, the MS takes different actions depending on the timer value received in the Back-off timer value IE (if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.13):

i) if the timer value indicates neither zero nor deactivated, the MS shall start the back-off timer with the value provided in the Back-off timer value IE for the PDP context modification procedure and PLMN and APN combination and not send another MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, in the PLMN for the same APN until the back-off timer expires, the MS is switched off or the SIM/USIM is removed;

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, in the PLMN for the same APN until the MS is switched off or the SIM/USIM is removed; or

iii) if the timer value indicates that this timer is zero, the MS may send an MODIFY PDP CONTEXT REQUEST message in the PLMN for the same APN.

If the Back-off timer value IE is not included, then the MS shall ignore the Re-attempt indicator IE provided by the network, if any.

i) Additionally, if the SM cause value is #32 "service option not supported", or #33 "requested service option not subscribed", the MS shall proceed as follows:

– otherwise, if the MS is not registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), or if the SM_RetryWaitTime value is not configured, the MS shall behave as described above in the present subclause, using the default value of 12 minutes for the back-off timer.

ii) For SM cause values different from #32 "service option not supported", or #33 "requested service option not subscribed", the MS behaviour regarding the start of a back-off timer is unspecified.

The MS shall not stop any back-off timer upon a PLMN change or inter-system change. If the network indicates that a back-off timer for the PDP context modification procedure and PLMN and APN combination is deactivated, then it remains deactivated upon a PLMN change or inter-system change.

NOTE 1: This means the back-off timer can still be running or be deactivated for the given SM procedure and PLMN and APN combination when the MS returns to the PLMN or when it performs inter-system change back from S1 mode to A/Gb or Iu mode. Thus the MS can still be prevented from sending another MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, in the PLMN for the same APN.

If the back-off timer is started upon receipt of a MODIFY PDP CONTEXT REQUEST message (i.e. the timer value was provided by the network, a configured value is available or the default value is used as explained above) or the back-off timer is deactivated, the MS behaves as follows:

i) after a PLMN change the MS may send a MODIFY PDP CONTEXT REQUEST message for the same APN in the new PLMN, if the back-off timer is not running and is not deactivated for the PDP context modification procedure and the combination of new PLMN and APN;

Furthermore as an implementation option, for the SM cause values #32 "service option not supported" or #33 "requested service option not subscribed", if the network does not include a Re-attempt indicator IE, the MS may decide not to automatically send another MODIFY PDP CONTEXT REQUEST message for the same APN, if the MS registered to a new PLMN which is in the list of equivalent PLMNs.

– if the MS is registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), the MS shall apply the configured SM_RetryAtRATChange value as specified in 3GPP TS 24.368 [135] or in USIM file NAS_CONFIG as specified in 3GPP TS 31.102 [112], if available, to determine whether the MS may attempt a bearer resource modification procedure for the same PLMN and APN combination in S1 mode; and

– if the MS is not registered in its HPLMN or in a PLMN that is within the EHPLMN list (if the EHPLMN list is present), or if the NAS configuration MO as specified in 3GPP TS 24.368 [135] is not available and the value for inter-system change is not configured in the USIM file NAS_CONFIG, then the MS behaviour regarding a bearer resource modification procedure for the same PLMN and APN combination in S1 mode is unspecified; and

iii) if the network includes the Re-attempt indicator IE indicating that re-attempt in an equivalent PLMN is not allowed, then depending on the timer value received in the Back-off timer value IE, for each combination of a PLMN from the equivalent PLMN list and the APN the MS shall start a back-off timer for the PDP context modification procedure with the value provided by the network, or deactivate the respective back-off timer as follows:

– If the Re-attempt indicator IE additionally indicates that re-attempt in S1 mode is allowed, the MS shall start or deactivate the back-off timer for A/Gb and Iu mode only; and

– otherwise the MS shall start or deactivate the back-off timer for A/Gb, Iu, and S1 mode.

If the back-off timer for a PLMN and APN combination was started or deactivated in S1 mode upon receipt of a BEARER RESOURCE MODIFICATION REJECT message (see 3GPP TS 24.301 [120]) and the network indicated that re-attempt in A/Gb or Iu mode is allowed, then this back-off timer does not prevent the MS from sending a MODIFY PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode. If the network indicated that re-attempt in A/Gb or Iu mode is not allowed, the MS shall not send any MODIFY PDP CONTEXT REQUEST message in this PLMN for the same APN in A/Gb or Iu mode until the timer expires, the MS is switched off or the USIM is removed.

NOTE 2: The back-off timer is used to describe a logical model of the required MS behaviour. This model does not imply any specific implementation, e.g. as a timer or timestamp.

6.1.3.3.3a Network initiated PDP Context Modification not accepted by the MS

Upon receipt of a MODIFY PDP CONTEXT REQUEST message, if the MS does not accept the new QoS due to resource reasons or the indicated LLC SAPI, the MS shall initiate the PDP context deactivation procedure for the PDP context – the reject cause IE value of the DEACTIVATE PDP CONTEXT REQUEST message shall indicate "QoS not accepted".

The MS may reject the network initiated PDP context modification request by sending a MODIFY PDP CONTEXT REJECT message to the network. The message shall contain a cause code that typically indicates one of the following:

# 41: semantic error in the TFT operation;

# 42: syntactical error in the TFT operation;

# 44: semantic errors in packet filter(s);

# 45: syntactical errors in packet filter(s);

# 48: request rejected, Bearer Control Mode violation; or

# 95 – 111: protocol errors.

The MS shall reply with a MODIFY PDP CONTEXT REJECT message with cause "request rejected, Bearer Control Mode violation", if the selected Bearer Control Mode is ‘MS only’ and the network requests to modify or delete a TFT

If a TFT modification was requested and the network requests to modify or delete packet filters which were added by the MS, then the MODIFY PDP CONTEXT REJECT message shall be sent.

The TFT in the request message is checked by the MS for different types of TFT IE errors as specified in subclause 6.1.3.3.4.

Upon receipt of a MODIFY PDP CONTEXT REJECT message, the network shall stop timer T3386 and enter the state PDP-ACTIVE.

6.1.3.3.4 Abnormal cases

a) Expiry of timers

On the network side:

On the first expiry of timer T3386, the network shall resend the MODIFY PDP CONTEXT REQUEST message reset and restart timer T3386. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3386, the network may continue to use the previously negotiated QoS and TFT, or it may initiate the PDP context deactivation procedure.

In the MS:

On the first expiry of timer T3381, the MS shall resend the MODIFY PDP CONTEXT REQUEST message reset and restart timer T3381. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3381, the MS may continue to use the previously negotiated QoS and TFT, or it may initiate the PDP context deactivation procedure.

b) Collision of MS and Network initiated PDP Context Modification Procedures

A collision of a MS and network initiated PDP context modification procedures is identified by the MS if a MODIFY PDP CONTEXT REQUEST message is received from the network after the MS has sent a MODIFY PDP CONTEXT REQUEST message itself, and both messages contain the same TI and the MS has not yet received a MODIFY PDP CONTEXT ACCEPT message from the network.

A collision is detected by the network in case a MODIFY PDP CONTEXT REQUEST message is received from the MS with the same TI as the MODIFY PDP CONTEXT REQUEST message sent to the MS.

In the case of such a collision, the network initiated PDP context modification shall take precedence over the MS initiated PDP context modification. The MS shall terminate internally the MS initiated PDP context modification procedure, enter the state PDP-Active and proceed with the network initiated PDP context modification procedure by sending a MODIFY PDP CONTEXT ACCEPT message. The network shall ignore the MODIFY PDP CONTEXT REQUEST message received in the state PDP-MODIFY-PENDING. The network shall proceed with the network initiated PDP context modification procedure as if no MODIFY PDP CONTEXT REQUEST message was received from the MS.

c) Collision of MS initiated PDP Context Modification Procedures and Network initiated Deactivate PDP Context Request Procedures

A collision of a MS initiated PDP context modification procedures and a network initiated PDP context deactivation procedures is identified by the MS if a DEACTIVATE PDP CONTEXT REQUEST message is received from the network after the MS has sent a MODIFY PDP CONTEXT REQUEST message, and the MS has not yet received a MODIFY PDP CONTEXT ACCEPT message from the network.

In the case of such a collision, the network initiated PDP context deactivation shall take precedence over the MS initiated PDP context modification. The MS shall terminate internally the MS initiated PDP context modification procedure, and proceed with the network initiated PDP context deactivation procedure by sending a DEACTIVATE PDP CONTEXT ACCEPT, enter the state PDP-INACTIVE. The network shall ignore the MODIFY PDP CONTEXT REQUEST message received in the state PDP-INACTIVE-PENDING. The network shall proceed with the network initiated PDP context deactivation procedure as if no MODIFY PDP CONTEXT REQUEST message was received from the MS.

d) MS initiated PDP context modification procedure for a PDN connection established for emergency bearer services.

The network shall reply with a MODIFY PDP CONTEXT REJECT message with a cause code indicating "activation rejected by GGSN, Serving GW or PDN GW".

The TFT in the MODIFY PDP CONTEXT REQUEST message is checked for different types of TFT IE errors as follows:

a) Semantic errors in TFT operations:

1) When the TFT operation is "Create a new TFT" and there is already an existing TFT for the PDP context.

2) When the TFT operation is an operation other than "Create a new TFT" and there is no TFT for the PDP context.

3) When the TFT operation is "Delete existing TFT" and the TFT includes packet filters created by the receiver of the request.

4) When the TFT operation is "Delete existing TFT" and there is already another PDP context with the same PDP address and APN without a TFT.

5) When the TFT operation is "Delete existing TFT" and the PDP context is not the default PDP context.

6) When the TFT operation is "Delete packet filters from existing TFT" or "Replace packet filters in existing TFT" and at least one of the packet filters to be deleted or replaced was created by the receiver of the request.

7) When the TFT operation is "Delete packet filters from existing TFT" and this operation would render the TFT empty.

In the above cases the network shall perform the following actions:

In case 1) the network shall further process the new activation request and, if it was processed successfully, delete the old TFT.

In case 2) the network shall:

– further process the new request and, if no error according to list items b), c), and d) was detected, consider the TFT as successfully deleted, if the TFT operation is "Delete existing TFT" or "Delete packet filters from existing TFT"; and

– process the new request as an activation request, if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT".

In case 3) the network shall reject the modification request with cause "semantic error in the TFT operation".

In case 4) the network shall either:

– reject the modification request with cause "semantic error in the TFT operation"; or

– optionally, if the BCM is "MS only" and the packet filters in the TFT do not have any explicit direction information, i.e. the packet filter direction parameter is set to "00", process the new deletion request and, after successful deletion of the TFT, deactivate the old PDP context with the same PDP address and APN without a TFT by explicit peer-to-peer signalling between the MS and the network.

– In case 5) the network shall either:

– reject the modification request with cause "semantic error in the TFT operation"; or

In case 6) the network shall reject the modification request with cause "semantic error in the TFT operation".

In case 7) the network shall:

i) if the PDP context is the default PDP context, further process the new request and, if no error according to list items b), c), and d) was detected, delete the existing TFT. After successful deletion of the TFT, if there was already another PDP context with the same PDP address and APN without a TFT, the network shall deactivate this old PDP context without a TFT by explicit peer-to-peer signalling between the MS and the network; and

ii) if the PDP context is not the default PDP context, further process the new request and, if no error according to list items b), c), and d) was detected, delete the existing TFT. After successful deletion of the TFT, the network shall deactivate the modified PDP context by explicit peer-to-peer signalling between the MS and the network. The network need not respond with a Modify PDP Context Accept message.

In the above cases the MS shall perform the following actions:

In case 1) the MS shall further process the new activation request and, if it was processed successfully, delete the old TFT.

In case 2) the MS shall:

– process the new request as an activation request, if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT".

In case 3) the MS shall reject the modification request with cause "semantic error in the TFT operation".

In case 4) the MS shall either:

A) reject the modification request with cause "semantic error in the TFT operation"; or

B) optionally, to support networks compliant with earlier versions of the protocol, process the new deletion request and, after successful deletion of the TFT, deactivate the old PDP context with the same PDP address and APN without a TFT by explicit peer-to-peer signalling between the MS and the network.

NOTE 1: This case is not expected to occur for a network implementing this version of the protocol, because at least one of the two PDP contexts without TFT will be a non-default PDP context. But for Bearer Control Mode ‘MS/NW’ such a network does not support an initial configuration where the old PDP context without TFT is a non-default PDP context, and the network will not attempt to delete the TFT of a non-default PDP context.

If during a previous inter-system change from S1 mode to A/Gb or Iu mode the default PDP context linked to the PDP context to be modified was mapped from an EPS bearer context, the MS shall follow option A.

In case 5) the MS shall either:

A) reject the modification request with cause "semantic error in the TFT operation"; or

B) optionally, to support networks compliant with earlier versions of the protocol, process the new deletion request.

NOTE 2: A network implementing this version of the protocol will not attempt to delete the TFT of a non-default PDP context.

In case 6) the MS shall reject the modification request with cause "semantic error in the TFT operation".

In case 7) the MS shall:

i) if the PDP context is the default PDP context, further process the new request and, if no error according to list items b), c), and d) was detected, delete the existing TFT. After successful deletion of the TFT, if there was already another PDP context with the same PDP address and APN without a TFT, the MS shall deactivate this old PDP context without a TFT by explicit peer-to-peer signalling between the MS and the network; and

ii) if the PDP context is not the default PDP context, either

– further process the new request and, if no error according to list items b), c), and d) was detected, delete the existing TFT. After successful deletion of the TFT, the MS shall deactivate the modified PDP context by explicit peer-to-peer signalling between the MS and the network. The MS need not send a Modify PDP Context Accept message; or

– reject the modification request with cause "semantic error in the TFT operation".

b) Syntactical errors in TFT operations:

1) When the TFT operation is an operation other than "Delete existing TFT" or "No TFT operation" and the packet filter list in the TFT IE is empty.

2) When the TFT operation is "Delete existing TFT" or "No TFT operation" with a non-empty packet filter list in the TFT IE.

3) When the TFT operation is "Replace packet filters in existing TFT" and the packet filter to be replaced does not exist in the original TFT.

4) When the TFT operation is "Delete packet filters from existing TFT" and the packet filter to be deleted does not exist in the original TFT.

5) Void.

6) When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.

7) When the TFT operation is "No TFT operation" with an empty parameters list.

In case 3) the network shall not diagnose an error, further process the replace request and, if no error according to list items c) and d) was detected, include the packet filters received to the existing TFT.

In case 4) the network shall not diagnose an error, further process the deletion request and, if no error according to list items c) and d) was detected, consider the respective packet filter as successfully deleted.

Otherwise the network shall reject the modification request with cause "syntactical error in the TFT operation".

In case 3) the MS shall not diagnose an error, further process the replace request and, if no error according to list items c) and d) was detected, include the packet filters received to the existing TFT.

In case 4) the MS shall not diagnose an error, further process the deletion request and, if no error according to list items c) and d) was detected, consider the respective packet filter as successfully deleted.

Otherwise the MS shall reject the modification request with cause "syntactical error in the TFT operation".

c) Semantic errors in packet filters:

1) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the receiver determines a semantic error in a packet filter is outside the scope of the present document.

2) When the resulting TFT, which is not assigned to the default PDP context, does not contain any packet filter applicable for the uplink direction.

NOTE 3: When BCM is ‘MS only’, the MS is allowed to include a TFT with packet filters without any explicit direction information, i.e. with value "00", and such packet filters are applicable for both uplink and downlink directions.

The network shall reject the modification request with cause "semantic errors in packet filter(s)".

The MS shall reject the modification request with cause "semantic errors in packet filter(s)".

d) Syntactical errors in packet filters:

1) When the TFT operation is "Create a new TFT" or "Add packet filters to existing TFT" and two or more packet filters in the resultant TFT would have identical packet filter identifiers.

2) When the TFT operation is "Create a new TFT" or "Add packet filters to existing TFT" or "Replace packet filters in existing TFT" and two or more packet filters in all TFTs associated with this PDP address and APN would have identical packet filter precedence values.

3) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.

In case 1), if two or more packet filters with identical packet filter identifiers are contained in the new request, the network shall reject the modification request with cause "syntactical errors in packet filter(s)". Otherwise, the network shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers.

In case 2) the network shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have identical filter precedence values. Furthermore, by means of explicit peer-to-peer signalling between the MS and the network, the network shall deactivate the PDP context(s) for which it has deleted the packet filters.

Otherwise the network shall reject the modification request with cause "syntactical errors in packet filter(s)".

In case 1), if two or more packet filters with identical packet filter identifiers are contained in the new request, the MS shall reject the modification request with cause "syntactical errors in packet filter(s)". Otherwise, the MS shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers.

In case 2) the MS shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have identical filter precedence values. Furthermore, the MS shall deactivate the PDP context(s) for which it has deleted the packet filters by means of explicit peer-to-peer signalling between the MS and the network,.

Otherwise, the MS shall reject the modification request with cause "syntactical errors in packet filter(s)".

Figure 6.6/3GPP TS 24.008: Network initiated PDP context modification procedure

Figure 6.7/3GPP TS 24.008: MS initiated PDP context modification procedure

6.1.3.4 PDP context deactivation procedure

The purpose of this procedure is to deactivate an existing PDP context between the MS and the network. The PDP context deactivation may be initiated by the MS or by the network. The tear down indicator information element may be included in the DEACTIVATE PDP CONTEXT REQUEST message in order to indicate whether only the PDP context associated with this specific TI or all active PDP contexts sharing the same PDP address and APN as the PDP context associated with this specific TI shall be deactivated. If the tear down is requested, all other active PDP contexts sharing the same PDP address and APN as the PDP context associated with this specific TI shall be deactivated locally without peer-to-peer signalling. In this case, the network should not include WLAN offload indication in the DEACTIVATE PDP CONTEXT REQUEST message, and if the UE receives the WLAN offload indication, the UE shall ignore the indication. If the tear down indicator information element is not included in the DEACTIVATE PDP CONTEXT REQUEST message, only the PDP context associated with this specific TI shall be deactivated. For an exception when the PDP context is a default PDP context and there are other active PDP contexts sharing the same PDP address and APN, see subclause 6.1.3.4.3.

An MS supporting S1 mode shall always include the tear down indicator when deactivating the default PDP context. An MS not supporting S1 mode should apply the same behavior (see 3GPP TS 23.060 [74]).

Local deactivation of a NBIFOM multi-access PDN connection can be triggered by an NBIFOM procedure (see 3GPP TS 24.161 [158]). If such a trigger is received then the associated PDP contexts mentioned in this specification shall be deactivated locally without peer-to-peer signalling.

After successful PDP context deactivation, the associated NSAPI and TI values are released and can be reassigned to another PDP context.

If one or more MBMS contexts are linked to a PDP context that has been deactivated, the MS shall deactivate all those MBMS contexts locally (without peer to peer signalling between the MS and the network).

The MS is allowed to initiate the PDP context deactivation procedure even if the timer T3396 is running.

6.1.3.4.1 PDP context deactivation initiated by the MS

In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-INACTIVE-PENDING and starts timer T3390. The message contains the transaction identifier (TI) in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes:

# 25: LLC or SNDCP failure (A/Gb mode only);

# 26: insufficient resources;

# 36: regular deactivation; or

# 37: QoS not accepted.

The network shall reply with the DEACTIVATE PDP CONTEXT ACCEPT message. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the MS shall stop timer T3390.

In A/Gb mode, both the MS and the network shall initiate local release of the logical link if it is not used by another PDP context.

In Iu mode, the network shall initiate the release of Radio Access Bearer associated with this PDP context.

If the selected Bearer Control Mode is ‘MS/NW’ the MS should not deactivate a PDP context, if it is the only PDP context without TFT within a group of active PDP contexts sharing the same PDP address and APN.

NOTE 1: A configuration with more than one PDP context without TFT within a group of active PDP contexts sharing the same PDP address and APN can occur during a network initiated PDP context modification due to asynchronous TFT states in the MS and in the network (see e.g. subclause 6.1.3.3.4 bullet a.3 in the description of the TFT checks).

NOTE 2: If the MS deactivates the last remaining PDP context without TFT within a group of active PDP contexts sharing the same PDP address and APN, a network implementing this version of the protocol will deactivate all other active PDP contexts sharing the same PDP address and APN by explicit peer-to-peer signalling; a network compliant with earlier versions of the protocol can initiate the re-establishment of this PDP context using the network requested secondary PDP context activation procedure.

6.1.3.4.2 PDP context deactivation initiated by the network

In order to deactivate a PDP context, the network sends a DEACTIVATE PDP CONTEXT REQUEST message to the MS and starts timer T3395. The message contains the transaction identifier in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes:

# 8: Operator Determined Barring;

# 25: LLC or SNDCP failure (A/Gb mode only);

# 26: insufficient resources;

# 36: regular deactivation;

# 38: network failure;

# 39: reactivation requested.

#112: APN restriction value incompatible with active PDP context; or

#113: Multiple accesses to a PDN connection not allowed.

The MS shall, upon receipt of this message, reply with a DEACTIVATE PDP CONTEXT ACCEPT message. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the network shall stop the timer T3395.

If the DEACTIVATE PDP CONTEXT REQUEST message includes the cause #39 "reactivation requested", the PDP context was activated by the MS, and the MS sent an APN for the establishment of the PDN connection, the MS shall stop timer T3396 if it is running for the APN sent by the MS. The MS should then re-activate the PDP context. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop the timer T3396 associated with no APN if it is running, and should re-activate the PDP context without including an APN. Additionally, the MS should re-activate the PDP contexts that were originally activated by the MS and released by the network as a result of this PDP context deactivation procedure. If the DEACTIVATE PDP CONTEXT REQUEST message was received for an emergency PDN connection, the MS shall not stop the timer T3396 associated with no APN if it is running. The MS should then re-initiate the PDP context activation procedure for the emergency PDN connection.

NOTE: User interaction is necessary in some cases when the MS cannot re-activate the PDP context(s) automatically.

If a detach is requested by the HLR for an MS that has PDP contexts for emergency services, the SGSN shall send a DEACTIVATE PDP CONTEXT REQUEST message to the MS for all the PDP contexts that are not PDP contexts for emergency services.

If the network operates in network operation mode I, ISR is activated and the MS has indicated support of EMM combined procedures in MS network capability, when the SGSN receives the request from the Serving GW for deactivating the last remaining PDP context, then the SGSN shall perform a detach procedure for non-GPRS services only as described in subclause 4.7.4.2.

In A/Gb mode, both the MS and the network shall initiate local release of the logical link if it is not used by another PDP context.

In Iu mode, the network shall initiate the release of Radio Access Bearer associated with this PDP context.

If the SM cause value is #26 "insufficient resources", the network may include a value for timer T3396 in the DEACTIVATE PDP CONTEXT REQUEST message.

If the SM cause value is #26 "insufficient resources" and T3396 value IE is included:

– the MS shall take different actions depending on the timer value received for timer T3396 (if the MS is configured for dual priority, exceptions are specified in subclause 6.1.3.12; if the MS is an MS configured to use AC11 – 15 in selected PLMN, exceptions are specified in subclause 6.1.3.11):

i) if the timer value indicates neither zero nor deactivated, the MS shall stop the timer T3396 associated with the corresponding APN, if it is running. The MS shall start timer T3396 with received value and not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN until timer T3396 expires or the timer T3396 is stopped. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall stop timer T3396 associated with no APN, if it is running. The MS shall then start timer T3396 with the value provided in the Back-off timer value IE and not send another ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without an APN sent by the MS, until timer T3396 expires or timer T3396 is stopped. The MS shall not stop timer T3396 upon a PLMN change or inter-system change;

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN until the MS is switched off or the SIM/USIM is removed or the MS receives a REQUEST PDP CONTEXT ACTIVATION, REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message with exception of those identified in subclause 6.1.3.3, for the same APN from the network or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for the same APN from the network. If the MS did not send an APN for the establishment of the PDN connection and the request type was different from "emergency", the MS shall not send another ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency", or another ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST with exception of those identified in subclause 6.1.3.3, for a non-emergency PDN connection established without an APN sent by the MS, until the MS is switched off or the SIM/USIM is removed or the MS receives any of the following messages: a REQUEST PDP CONTEXT ACTIVATION without an APN, a REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without an APN sent by the MS, or a DEACTIVATE PDP CONTEXT REQUEST message including SM cause #39 "reactivation requested" for a PDP context which was activated by the MS for a non-emergency PDN connection established without APN sent by the MS. The timer T3396 remains deactivated upon a PLMN change or inter-system change; and

iii) if the timer value indicates that this timer is zero, the MS:

– shall stop timer T3396 associated with the corresponding APN, if running, and may send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for the same APN; and

– If the timer T3396 is running when the MS enters state GMM-DEREGISTERED, the MS remains switched on, and the SIM/USIM in the MS remains the same, then timer T3396 is kept running until it expires or it is stopped.

– if the MS is switched off when the timer T3396 is running, the MS shall behave as follows when the MS is switched on and the SIM/USIM in the MS remains the same:

– if prior to switch off, timer T3396 was running because an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message containing the low priority indicator set to "MS is configured for NAS signalling low priority" was rejected with timer T3396, and if timer T3396 is restarted at switch on, then the MS configured for dual priority shall handle session management requests as indicated in subclause 6.1.3.12.

If the T3396 value IE is not included, the MS shall proceed with deactivation procedure and then send DEACTIVATE PDP CONTEXT ACCEPT message.

6.1.3.4.3 Abnormal cases

The following abnormal cases can be identified:

a) Expiry of timers

In the mobile station:

On the first expiry of timer T3390, the MS shall resent the message DEACTIVATE PDP CONTEXT REQUEST and shall reset and restart the timer T3390. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3390, the MS shall release all resources allocated and shall erase the PDP context related data.

On the network side:

On the first expiry of timer T3395, the network shall resent the message DEACTIVATE PDP CONTEXT REQUEST and shall reset and restart timer T3395. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3395, the network shall erase the PDP context related data for that MS.

b) Collision of MS and network initiated PDP context deactivation requests

If the MS and the network initiated PDP context deactivation requests collide, the MS and the network shall each reply with the messages DEACTIVATE PDP CONTEXT ACCEPT and shall stop timer T3390 and T3395, respectively.

c) Network initiated PDP context deactivation request without tear down indicator information element for a default PDP context

If an MS supporting S1 mode receives a DEACTIVATE PDP CONTEXT REQUEST message without tear down indicator information element, and the PDP context associated with the specific TI is a default PDP context, the MS shall deactivate the default PDP context as specified in subclause 6.1.3.4.2. Additionally the MS shall deactivate all other active PDP contexts sharing the same PDP address and APN as the default PDP context locally without peer-to-peer signalling.

An MS not supporting S1 mode may apply the same behaviour.

Figure 6.8/3GPP TS 24.008: MS initiated PDP context deactivation procedure

Figure 6.9/3GPP TS 24.008: Network initiated PDP context deactivation procedure

6.1.3.4a Void

6.1.3.5 Void

6.1.3.5a Notification procedure

6.1.3.5a.1 General

The network can use the notification procedure to inform the MS about events which are relevant for the upper layer which is using a PDP context or has requested a session management procedure.

If the MS has indicated that it supports the notification procedure, the network may initiate the procedure at any time while a PDP context is activated or another session management procedure is ongoing.

6.1.3.5a.2 Notification procedure initiation by the network

The network initiates the notification procedure by sending a NOTIFICATION message to the MS (see example in figure 6.9a/3GPP TS 24.008).

Network

NOTIFICATION

Figure 6.9a/3GPP TS 24.008: Notification procedure

6.1.3.5a.3 Notification procedure in the MS

When the MS receives a NOTIFICATION message, the SM protocol entity in the MS shall provide the notification indicator to the upper layer.

The notification indicator can have the following value:

#1: SRVCC handover cancelled, IMS session re-establishment required.

6.1.3.6 Receiving a SM STATUS message by a SM entity

If the SM entity of the MS receives an SM STATUS message the MS shall take different actions depending on the received SM cause value:

#81 Invalid transaction identifier value

The MS shall abort any ongoing SM procedure related to the received transaction identifier value, stop any related timer, and deactivate the corresponding PDP or MBMS context locally (without peer to peer signalling between the MS and the network).

If one or more MBMS contexts are linked to a PDP context that has been deactivated, the MS shall deactivate all those MBMS Contexts locally (without peer to peer signalling between the MS and the network).

#97 Message type non-existent or not implemented

The MS shall abort any ongoing SM procedure related to the received transaction identifier value and stop any related timer.

If the SM entity of the MS receives a SM STATUS message with any other SM cause value no state transition and no specific action shall be taken as seen from the radio interface, i.e. local actions are possible.

If the SM entity of the network receives an SM STATUS message the network shall take different actions depending on the received SM cause value:

#81 Invalid transaction identifier value

The network shall abort any ongoing SM procedure related to the received transaction identifier value, stop any related timer, and deactivate the corresponding PDP or MBMS context locally (without peer to peer signalling between the MS and the network).

#97 Message type non-existent or not implemented

The network shall abort any ongoing SM procedure related to the received transaction identifier value and stop any related timer.

The actions to be taken in the network on receiving a SM STATUS message with any other SM cause value are an implementation dependent option.

6.1.3.7 Protocol configuration options

The MS and the GGSN may communicate parameters by means of the protocol configuration options information element or extended protocol configuration options information element when activating, modifying or deactivating a PDP context. Such parameters can e.g. be used to convey information from external protocols between the MS and the GGSN. An overview of how the protocol configuration options information element is used is specified in 3GPP TS 27.060 [36a].

The protocol configuration options information element and the extended protocol configuration options information element is transparent to the SGSN.

NOTE 1: The MS and the network negotiate support of the extended protocol configuration options IE end-to-end for each PDN connection, as the information element can only be used if it is supported also by the GGSN/PDN GW.

If supported by the network and the MS end-to-end for a PDN connection, protocol configuration options shall be exchanged via the extended protocol configuration options IE. Otherwise the protocol configuration options IE is used.

For the MS, the extended protocol configuration options is supported by the network and the MS end-to-end for a PDN connection if the network has indicated support of the extended protocol configuration options IE in the last ATTACH ACCEPT or ROUTING AREA UPDATING ACCEPT message, and

– the PDP Type requested for the default PDP context is non-IP; or

– the network has included the extended protocol configuration options IE in at least one session management message received by the MS for this PDN connection.

For the SGSN, the extended protocol configuration options is supported by the network and the MS end-to-end for a PDN connection if the MS has indicated support of the extended protocol configuration options IE in the last ATTACH REQUEST or ROUTING AREA UPDATING REQUEST message, and

– the PDP Type requested for the default PDP context is non-IP; or

– the SGSN has received the extended protocol configuration options IE in at least one message sent by the GGSN or PDN GW towards the MS for this PDN connection (for details see 3GPP TS 29.274 [16D]).

NOTE 2: For the GGSN or PDN GW, the extended protocol configuration options is supported by the network and the MS end-to-end for a PDN connection if:

– the GGSN initiates a network requested PDP context activation with offered PDP Type non-IP; or

– the last support indication received from the SGSN or S-GW indicates that extended protocol configuration options is supported for this PDN connection (for details see 3GPP TS 29.274 [16D]).

6.1.3.8 MBMS context activation

The purpose of this procedure is to establish an MBMS context in the MS and in the network for a specific IP Multicast Address using a specific NSAPI for MBMS user plane transmission. The MS shall only initiate the MBMS context activation when requested by the network. However, the trigger for the activation request by the network is initiated by the MS at the application layer (see 3GPP TS 23.246 [106]).

6.1.3.8.1 Successful MBMS context activation

In order to request an MBMS context activation, the network sends a REQUEST MBMS CONTEXT ACTIVATION message to the MS, enters the state MBMS-ACTIVE-PENDING and starts timer T3385. The message shall contain the IP multicast address, the APN and the Linked NSAPI.

Upon receipt of a REQUEST MBMS CONTEXT ACTIVATION message, the MS shall validate the message by verifying the NSAPI given in the Linked NSAPI IE to be one of the active PDP context(s), stop the timer T3396 if it is running for the APN indicated in the message and send an ACTIVATE MBMS CONTEXT REQUEST, enter state MBMS-ACTIVE-PENDING and start timer T3380. The message shall contain an IP multicast address and an APN, which shall be the same as the IP multicast address and the APN requested by the network in the REQUEST MBMS CONTEXT ACTIVATION message. Furthermore, the MS shall include the Supported MBMS bearer capabilities, i.e. the maximum downlink bit rate the MS can handle.

Upon receipt of the ACTIVATE MBMS CONTEXT REQUEST message, the network shall stop timer T3385. If the network accepts the request, it shall reply with an ACTIVATE MBMS CONTEXT ACCEPT message.

Upon receipt of the message ACTIVATE MBMS CONTEXT ACCEPT the MS shall stop timer T3380 and shall enter the state MBMS-ACTIVE.

6.1.3.8.2 Unsuccessful MBMS context activation requested by the MS

6.1.3.8.2.1 General

Upon receipt of an ACTIVATE MBMS CONTEXT REQUEST message the network may reject the MS initiated MBMS context activation by sending an ACTIVATE MBMS CONTEXT REJECT message to the MS. The sender of the message shall include the same TI as included in the ACTIVATE MBMS CONTEX REQUEST and an additional cause code that typically indicates one of the following causes:

# 8: Operator Determined Barring;

# 24: MBMS bearer capabilities insufficient for the service;

# 26: insufficient resources;

# 27: missing or unknown APN;

# 29: user authentication failed;

# 30: activation rejected by GGSN, Serving GW or PDN GW;

# 31: activation rejected, unspecified;

# 32: service option not supported;

# 33: requested service option not subscribed;

# 34: service option temporarily out of order; or

# 95 – # 111: protocol errors.

The network may include a Back-off timer value IE in the ACTIVATE MBMS CONTEXT REJECT message.

If the Back-off timer value IE is included and the SM cause value is different from #26 "insufficient resources", the network may include the Re-attempt indicator IE to indicate whether the MS is allowed to attempt an MBMS context activation procedure in an equivalent PLMN.

Upon receipt of an ACTIVATE MBMS CONTEXT REJECT message, the MS shall stop timer T3380 and enter/remain in state PDP-INACTIVE.

6.1.3.8.2.2 Handling of network rejection due to SM cause #26

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE MBMS CONTEXT REQUEST message for the same APN that was sent by the MS, until the MS is switched off or the SIM/USIM is removed or the MS receives REQUEST MBMS CONTEXT ACTIVATION message for the same APN from the network. The timer T3396 remains deactivated upon a PLMN change or inter-system change; and

iii) if the timer value indicates that this timer is zero, the MS may send another ACTIVATE MBMS CONTEXT REQUEST message for the same APN.

If the Back-off timer value IE is not included, then the MS may send another ACTIVATE MBMS CONTEXT REQUEST message for the same APN.

If the MS is switched off when the timer T3396 is running, the MS shall behave as follows when the MS is switched on and the SIM/USIM in the MS remains the same:

– if prior to switch off, timer T3396 was running because an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST, MODIFY PDP CONTEXT REQUEST or ACTIVATE MBMS CONTEXT REQUEST message containing the low priority indicator set to "MS is configured for NAS signalling low priority" was rejected with timer T3396, and if timer T3396 is restarted at switch on, then the MS configured for dual priority shall handle session management requests as indicated in subclause 6.1.3.12.

6.1.3.8.2.3 Handling of network rejection due to SM cause other than SM cause #26

If the SM cause value is different from #26 "insufficient resources", and the Back-off timer value IE is included, the MS shall take different actions depending on the timer value received in the Back-off timer value IE:

i) if the timer value indicates neither zero nor deactivated, the MS shall start the back-off timer with the value provided in the Back-off timer value IE for the MBMS context activation procedure and PLMN and APN combination. The MS shall not send another ACTIVATE MBMS CONTEXT REQUEST message in the PLMN for the same APN that was sent by the MS until the back-off timer expires, the MS is switched off or the SIM/USIM is removed;

ii) if the timer value indicates that this timer is deactivated, the MS shall not send another ACTIVATE MBMS CONTEXT REQUEST message in the PLMN for the same APN that was sent by the MS until the MS is switched off or the SIM/USIM is removed; and

iii) if the timer value indicates that this timer is zero, the MS may send an ACTIVATE MBMS CONTEXT REQUEST message in the PLMN for the same APN.

If the Back-off timer value IE is not included, then the MS shall ignore the Re-attempt indicator IE provided by the network, if any.

The MS shall not stop any back-off timer upon a PLMN change or inter-system change. If the network indicates that a back-off timer for the MBMS context activation procedure and PLMN and APN combination is deactivated, then it remains deactivated upon a PLMN change or inter-system change.

NOTE 1: This means the back-off timer can still be running or be deactivated for the given SM procedure and PLMN and APN combination when the MS returns to the PLMN or when it performs inter-system change back from S1 mode to A/Gb or Iu mode. Thus the MS can still be prevented from sending another ACTIVATE MBMS CONTEXT REQUEST message in the PLMN for the same APN.

If the back-off timer is started upon receipt of an ACTIVATE MBMS CONTEXT REJECT message (i.e. the timer value was provided by the network, a configured value is available or the default value is used as explained above) or the back-off timer is deactivated, the MS behaves as follows:

i) after a PLMN change the MS may send an ACTIVATE MBMS CONTEXT REQUEST message for the same APN in the new PLMN, if the back-off timer is not running and is not deactivated for the MBMS context activation procedure and the combination of new PLMN and APN;

Furthermore as an implementation option, for the SM cause values #8 "operator determined barring", #27 "missing or unknown APN", #32 "service option not supported" or #33 "requested service option not subscribed", if the network does not include a Re-attempt indicator IE, the MS may decide not to automatically send another ACTIVATE MBMS CONTEXT REQUEST message for the same APN, if the MS registered to a new PLMN which is in the list of equivalent PLMNs.

ii) if the network includes the Re-attempt indicator IE, the MS shall ignore any indication provided in the IE regarding whether re-attempt in S1 mode is allowed. If the Re-attempt indicator IE indicates that re-attempt in an equivalent PLMN is not allowed, then depending on the timer value received in the Back-off timer value IE, for each combination of a PLMN from the equivalent PLMN list and the APN the MS shall start a back-off timer for the MBMS context activation procedure with the value provided by the network, or deactivate the respective back-off timer.

NOTE 2: The back-off timer is used to describe a logical model of the required MS behaviour. This model does not imply any specific implementation, e.g. as a timer or timestamp.

6.1.3.8.3 Unsuccessful MBMS context activation requested by the network

Upon receipt of the REQUEST MBMS CONTEXT ACTIVATION message, the MS may reject the network requested MBMS context activation by sending the REQUEST MBMS CONTEXT ACTIVATION REJECT message to the network. The sender of the message shall include the same TI as included in the REQUEST MBMS CONTEXT ACTIVATION and an additional cause code that typically indicates one of the following causes:

# 26: insufficient resources;

# 31: activation rejected, unspecified;

# 40: feature not supported; or

# 95 – # 111: protocol errors.

The network shall stop timer T3385 and enter in state PDP-INACTIVE.

6.1.3.8.4 Abnormal cases

The following abnormal cases can be identified:

a) Expiry of timers in the mobile station: On the first expiry of the timer T3380, the MS shall resend the ACTIVATE MBMS CONTEXT REQUEST and shall reset and restart timer T3380. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3380, the MS shall release all resources possibly allocated for this invocation and shall abort the procedure; no automatic MBMS context activation re-attempt shall be performed.

b) Expiry of timers on the network side: On the first expiry of the timer T3385, the network shall resend the message REQUEST MBMS CONTEXT ACTIVATION and shall reset and restart timer T3385. This retransmission is repeated four times, i.e. on the fifth expiry of timer T3385, the network shall release possibly allocated resources for this activation and shall abort the procedure.

c) MBMS context activation request for an already activated MBMS context (on the mobile station side): If the MS receives a REQUEST MBMS CONTEXT ACTIVATION message with the same combination of APN and IP multicast address (i.e. PDP type and PDP address) as an already activated MBMS context, the MS shall deactivate the existing MBMS context locally without notification to the network and proceed with the requested MBMS context activation.

d) MBMS context activation request for an already activated MBMS context (on the network side): If the network receives an ACTIVATE MBMS CONTEXT REQUEST message with the same combination of APN and IP multicast address (i.e. PDP type and PDP address) as an already activated MBMS context, the network shall deactivate the existing MBMS context locally without notification to the MS and proceed with the requested MBMS context activation.

Figure 6.10/3GPP TS 24.008: MBMS context activation procedure

6.1.3.9 MBMS context deactivation

The purpose of this procedure is to deactivate an existing MBMS context in the MS and the network. The MS shall only initiate the MBMS context deactivation when requested by the network, however the trigger for the deactivation request by the network may be initiated by the MS at application layer or by the network, see 3GPP TS 23.246 [106].

After a successful MBMS context deactivation, the associated MBMS NSAPI and TI values shall be released in both the MS and the network and can be reassigned to another MBMS context.

The MBMS context deactivation procedure makes use of the messaging and signalling of the PDP context deactivation procedure as described in the subclauses 6.1.3.9.1 and 6.1.3.9.2.

6.1.3.9.1 MBMS context deactivation initiated by the network

In order to request an MBMS context deactivation, the network sends a DEACTIVATE PDP CONTEXT REQUEST message to the MS, enters the state MBMS-INACTIVE-PENDING and starts timer T3395. The message contains the transaction identifier (TI) in use for the MBMS context to be deactivated and a cause code that typically indicates one of the following causes:

# 36: regular deactivation;

# 38: network failure;

# 47: multicast group membership time-out.

The MS shall reply with a DEACTIVATE PDP CONTEXT ACCEPT message and enter the state PDP-INACTIVE. Upon receipt of the DEACTIVATE PDP CONTEXT ACCEPT message, the network shall stop the timer T3395 and enter the state PDP-INACTIVE.

6.1.3.9.2 Abnormal cases

The following abnormal cases can be identified:

a) Expiry of timers:

On the first expiry of the timer T3395, the network shall resend the message DEACTIVATE PDP CONTEXT REQUEST and shall reset and restart the timer T3395. This retransmission is repeated, i.e. on the fifth expiry of the timer T3395, the network shall erase the MBMS context related data for that MS.

Figure 6.11/3GPP TS 24.008: MBMS context deactivation procedure

6.1.3.10 MBMS protocol configuration options

The MS and the GGSN may communicate parameters related to the MBMS bearer by means of the MBMS protocol configuration options information element when activating or deactivating an MBMS context. For example, such parameters can be used to convey information between the MS and the GGSN.

The MBMS protocol configuration options information element is transparent to the SGSN.

6.1.3.11 Handling of APN based congestion control

The network may detect and start performing the APN based congestion control when one or more APN congestion criteria as specified in 3GPP TS 23.060 [74] are met. The network may store an APN congestion back-off time on a per MS and congested APN basis. If the MS does not provide an APN for the PDP context activation, then the SGSN uses the APN which is used in GGSN/PDN GW selection procedure as congested APN. When APN based congestion control is active, the network may reject session management requests except the modify PDP context requests from UEs or deactivate existing PDP contexts with SM cause value #26 "insufficient resources".

In the MS, session management timers T3396 for APN based congestion control are started and stopped on a per APN basis. The APN associated with T3396 is the APN sent by the MS when the PDN connection is established. If no APN is included in the ACTIVATE PDP CONTEXT REQUEST message, then T3396 is associated with no APN. For this purpose the MS shall memorize the APN provided to the network during the PDP context activation. The timer T3396 associated with no APN will never be started due to any SM procedure related to an emergency PDN connection. If the timer T3396 associated with no APN is running, it does not affect the ability of the MS to request an emergency PDN connection.

If timer T3396 is running or is deactivated, and the MS is an MS configured to use AC11 – 15 in selected PLMN, then the MS is allowed to initiate any session management procedure for the respective APN.

6.1.3.11A Handling of group specific session management congestion control

The network may detect and start performing the group specific session management congestion control when one or more group congestion criteria as specified in 3GPP TS 23.060 [74] are met. When group specific session management congestion control is active, the mechanism for APN based congestion control as specified in subclause 6.1.3.11 shall be followed.

6.1.3.12 Handling session management request for MS configured for dual priority

If timer T3396 is running for a specific APN due to one of the following reasons:

– an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST, MODIFY PDP CONTEXT REQUEST or ACTIVATE MBMS CONTEXT REQUEST message containing the low priority indicator set to "MS is configured for NAS signalling low priority" was rejected with a timer value for timer T3396 and SM cause value #26 "insufficient resources";

– a DEACTIVATE PDP CONTEXT REQUEST message was received with a timer value for timer T3396 and SM cause value #26 "insufficient resources" for a PDP context established with the low priority indicator set to "MS is configured for NAS signalling low priority", or

– because the MS received a DEACTIVATE PDP CONTEXT REQUEST message containing a timer value for timer T3396 and SM cause value #26 "insufficient resources" for a PDP context established with the low priority indicator set to "MS is configured for NAS signalling low priority";

upon request of the upper layers the MS can:

– send an ACTIVATE PDP CONTEXT REQUEST or ACTIVATE MBMS CONTEXT REQUEST message to the same APN, with low priority indicator set to "MS is not configured for NAS signalling low priority"; or,

– send an ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message, with low priority indicator set to "MS is not configured for NAS signalling low priority", for an active PDP context established with low priority indicator set to "MS is not configured for NAS signalling low priority" exists.

If timer T3396 is running, because any of the following messages containing the low priority indicator set to "MS is configured for NAS signalling low priority" was rejected with a timer value for timer T3396 and SM cause value #26 "insufficient resources":

– an ACTIVATE PDP CONTEXT REQUEST without an APN and with request type different from "emergency"; or

– an ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message for a non-emergency PDN connection established without APN sent by the MS,

or because the MS received a DEACTIVATE PDP CONTEXT REQUEST message containing a timer value for timer T3396 and SM cause value #26 "insufficient resources" for a non-emergency PDN connection established without an APN and established with the low priority indicator set to "MS is configured for NAS signalling low priority", then upon request of the upper layers the MS can:

– send an ACTIVATE PDP CONTEXT REQUEST message without an APN and with low priority indicator set to "MS is not configured for NAS signalling low priority" for establishment an non-emergency PDN connection; or

– send an ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST message, with low priority indicator set to "MS is not configured for NAS signalling low priority", for an active non-emergency PDP context established without an APN and with low priority indicator set to "MS is not configured for NAS signalling low priority".

For requests with low priority indicator set to "MS is configured for NAS signalling low priority", the MS shall follow the procedures specified in subclause 6.1.3.1.3.

6.1.3.13 Handling of network rejection not due to APN based congestion control

The network may include a back-off timer value in a session management reject message to regulate the time interval at which the MS may retry the same procedure. For SM cause values other than #26 "insufficient resources", the network may also include the re-attempt indicator to indicate whether the MS is allowed to re-attempt the corresponding EPS session management procedure for the same APN in S1 mode after inter-system change.

NOTE 1: If the network includes this back-off timer value, then the MS is blocked from sending another SM request for the same procedure for the same PLMN and APN combination for the specified duration. Therefore, the operator needs to exercise caution in determining the use of this timer value.

NOTE 2: If the re-attempt indicator is not provided by the network, an MS registered in its HPLMN or in an EHPLMN (if the EHPLMN list is present) can use the configured SM_RetryAtRATChange value specified in the NAS configuration MO or in the USIM NAS_CONFIG file to derive the re-attempt indicator as specified in subclauses 6.1.3.1.3.3, 6.1.3.2.2.3, and 6.1.3.3.3.3.

If re-attempt in S1 mode is allowed, the MS shall consider the back-off timer to be applicable only to the GPRS session management in A/Gb and Iu mode for the rejected session management procedure and the given PLMN and APN combination. If re-attempt in S1 mode is not allowed, the MS shall consider the back-off timer to be applicable to both NAS protocols, i.e. applicable to the GPRS session management in A/Gb and Iu mode for the rejected session management procedure and to the EPS session management in S1 mode for the corresponding EPS session management procedure and the given PLMN and APN combination.

The APN of the PLMN and APN combination associated with the back-off timer is the APN sent by the MS when the PDN connection is established. If no APN is included in the ACTIVATE PDP CONTEXT REQUEST message, then the back-off timer is associated with the combination of the PLMN and no APN. For this purpose the MS shall memorize the APN provided to the network during the PDP context activation. The back-off timer associated with the combination of a PLMN with no APN will never be started due to any SM procedure related to an emergency PDN connection. If the back-off timer associated with the combination of a PLMN with no APN is running, it does not affect the ability of the MS to request an emergency PDN connection.

The network may additionally indicate in the re-attempt indicator that a command to back-off is applicable not only for the PLMN in which the MS received the session management reject message, but for each PLMN included in the equivalent PLMN list at the time when the session management reject message was received.

If the back-off timer is running or is deactivated for a given PLMN and APN combination, and the MS is an MS configured to use AC11 – 15 in selected PLMN, then the MS is allowed to initiate any GPRS session management procedure for this PLMN and APN combination.

6.1.3.14 Handling of WLAN offload control

In networks that support offloading of traffic to WLAN, as specified in 3GPP TS 25.331 [23c], a permission to offload is determined for the MS and the PDP context in accordance with 3GPP TS 23.060 [74] subclause 5.3.21.