Section: 6.1.3.3.4 Abnormal cases
Content: 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 - 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. 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: - 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 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. 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 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". NOTE 2a: An implementation that strictly follows packet filter list as defined in subclause 10.5.6.12 might not detect case 2). 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[ Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 ] : Network initiated PDP context modification procedure Figure 6.7/3GPP TS 24.008[ Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 ] : MS initiated PDP context modification procedure