11.2 PDP context modification procedure
34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification
11.2.1 Network initiated PDP context modification
11.2.1.1 Definition
11.2.1.2 Conformance requirement
In order to initiate the procedure, the network sends the MODIFY PDP CONTEXT REQUEST message to the UE 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 UE in GSM at the lower layers for the transmission of data related to the PDP context.
Upon receipt of this message the UE shall reply with the MODIFY PDP CONTEXT ACCEPT message, if the UE accepts the new QoS and the indicated LLC SAPI.
If the UE does not accept the new QoS or the indicated LLC SAPI, the UE 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 network shall upon receipt of the MODIFY PDP CONTEXT ACCEPT message stop timer T3386.
In UMTS, the network shall establish, reconfigure or continue using the Radio Access Bearer with the new QoS indicated in the MODIFY PDP CONTEXT REQUEST message.
Reference
3GPP TS 24.008 clauses 6.1.3.3 and 6.1.3.3.1.
11.2.1.3 Test purpose
To test behaviour of the UE upon receipt of a MODIFY PDP CONTEXT REQUEST message from SS.
11.2.1.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– PS Supported yes/no
– Method of activating a PDP context
– Support of automatic PS attach procedure at switch on yes/no
Test procedure
The requested QoS is set. A PDP context is activated by the user and accepted by the SS. A MODIFY PDP CONTEXT REQUEST message is then sent to the UE with a new QoS . The UE shall either send a DEACTIVATE PDP CONTEXT REQUEST (UE behaviour A) or MODIFY PDP CONTEXT ACCEPT (UE behaviour B) message in return.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate the PDP context |
|
2a |
SS |
SS establishes RAB |
||
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
Request the modification of a PDP context, with a new QoS and start timer T3386. |
|
A5 |
|
DEACTIVATE PDP CONTEXT REQUEST |
UE behaviour type A: Initiate the PDP context deactivation. Cause set to ‘QoS not accepted’ |
|
A5a |
|
DEACTIVATE PDP CONTEXT ACCEPT |
UE behaviour type A: Accept the PDP context deactivation and stop timer T3386. |
|
A5b |
SS |
The SS releases the RAB associated with this PDP Context. |
||
A5c |
|
DETACH REQUEST |
UE behaviour type A: A non-auto attach UE may (optionally) send a Detach Request. The SS shall wait up to ‘T3390’ seconds for the Detach Request. |
|
A5d |
|
DETACH ACCEPT |
If the UE transmitted a Detach Request message in step A5c then the SS responds with a Detach Accept message. |
|
B5 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
UE behaviour type B: Accept the PDP context modification |
|
B5a |
SS |
Stop timer T3386 |
||
6 |
Void |
|||
7 |
Void |
|||
8 |
Void |
Specific message contents
None.
11.2.1.5 Test requirements
The UE shall:
– Accept or reject PDP context modification with a new QoS initiated by the SS.
11.2.1a Network initiated PDP context modification / Adding and deleting filters to TFT of a secondary PDP context
11.2.1a.1 Definition
11.2.1a.2 Conformance requirement
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 modified packet filters in the TFT information element that shall be applied to that specific PDP context.
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.
Upon receipt of the MODIFY PDP CONTEXT REQUEST message the MS shall 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.
…
Each valid downlink- and uplink-packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique among all packet filters for the same direction (downlink or uplink) for one PDP address and APN pair, and at least one of the following attributes:
– Remote Address and Subnet Mask.
– Protocol Number (IPv4) / Next Header (IPv6).
– Local Port Range.
– Remote Port Range.
– IPSec Security Parameter Index (SPI).
– Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
– Flow Label (IPv6).
In the list of attributes above ‘Remote’ refers to the external network entity, and ‘Local’ to the MS.
Some of the above-listed attributes may coexist in a packet filter while others mutually exclude each other. In table 12 below, the possible combinations are shown. Only those attributes marked with an "X" may be specified for a single packet filter. All marked attributes may be specified, but at least one shall be specified.
If the parameters of the header of a received PDP PDU match all specified attribute values in a packet filter, then it is considered that a match is found for this packet filter. In this case, the evaluation procedure is aborted. Other packet filters in increasing order of their evaluation precedence index are evaluated until such match is found.
There may be potential conflicts if attribute values are combined in such a way that the defined filter can never achieve a match to a valid IP packet header. However, the determination of such conflicts is outside the scope of GPRS standardization.
Table 12: Valid Packet Filter Attribute Combinations
Valid combination types |
|||
Packet filter attribute |
I |
II |
III |
Remote Address and Subnet Mask |
X |
X |
X |
Protocol Number (IPv4) / Next Header (IPv6) |
X |
X |
|
Local Port Range |
X |
||
Remote Port Range |
X |
||
IPSec SPI |
X |
||
TOS (IPv4) / Traffic Class (IPv6) and Mask |
X |
X |
X |
Flow Label (IPv6) |
X |
Reference
3GPP TS 24.008 clauses 6.1.3.3 and 6.1.3.3.1. 3GPP TS 23.060 clause 15.3.2.0.
11.2.1a.3 Test purpose
1. To verify that the UE successfully performs network initiated PDP context modification procedures to add and delete filters to the TFT of an active secondary PDP context.
2. To verify that the UE successfully performs packet filtering before and after modification of filters.
11.2.1a.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– Method of activating a PDP context
– Support of automatic PS attach procedure at switch on yes/no
Test procedure
A PDP context activation is requested by the user and accepted by the SS.
If the UE set the PDP type to ‘IPv4’ in the ACTIVATE PDP CONTEXT REQUEST then the SS allocates a IPv4 address to the UE and set the test variable IP type to “IPv4”. If the UE sets the PDP type to IPv4v6 in the ACTIVATE PDP CONTEXT then the SS allocates an IPv4v6 address to the UE.
Else if the UE set the PDP type to ‘IPv6’ in the ACTIVATE PDP CONTEXT REQUEST then the SS allocates an IPv6 address via stateless address auto configuration on the established primary PDP context and set the test variable IP type to “IPv6”. A Secondary PDP context activation with a UL TFT filter (Packet Filter#1) is requested by the SS and the activation procedure is completed by the UE.
The SS activates UE test loop mode 4 and transmits two IP Packets to the UE, IP packet#1 and IP packet#2. IP packet#1 does not match Packet Filter#1. IP packet#2 matches Packet Filter#1. The SS checks that IP packet#1 is returned by the UE on the radio bearer associated with the primary PDP context and IP packet#2 is returned by the UE on the radio bearer associated with the secondary PDP context. The SS sends a MODIFY PDP CONTEXT REQUEST message to the UE requesting a new TFT filter to be added, Packet Filter#2. The UE sends a MODIFY PDP CONTEXT ACCEPT message in return.
The SS transmits three IP Packets to the UE, IP packet#3; IP packet#4 and IP packet#5. IP packet#3 does not match Packet Filter#1 nor Packet Filter#2. IP packet#4 matches Packet Filter#1, but not Packet Filter#2. IP packet#5 matches Packet Filter#2, but not Packet Filter#1. The SS checks that IP packet#3 is returned by the UE on the radio bearer associated with the primary PDP context. The SS checks that IP packet#4 and IP packet#5 are returned by the UE on the radio bearer associated with the secondary PDP context. The SS sends a MODIFY PDP CONTEXT REQUEST message to the UE requesting Packet Filter#1 to be removed from the TFT. The UE sends a MODIFY PDP CONTEXT ACCEPT message in return.
The SS transmits two IP Packets to the UE, IP packet#6 and IP packet#7. IP packet#6 matches Packet Filter#1, but not Packet Filter#2. IP packet#7 matches Packet Filter#2. The SS checks that IP packet#6 is returned by the UE on the radio bearer associated with the primary PDP context (see Note). The SS checks that IP packet#7 is returned by the UE on the radio bearer associated with the secondary PDP context. Note IP packet#6 is set to match Packet Filter#1, but not Packet Filkter#2 to verify that UE have successfully removed Packet Filter#1. If Packet Filter#1 would not have been removed by the UE then would IP packet#6 have been returned on the radio bearer associated with the secondary PDP context instead of the primary PDP context.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
SS |
The SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to either Originating Streaming Call, Originating Interactive Call or Originating Background Call or OriginatingSubscribedTrafficCall |
||
2 |
SS |
|||
3 |
|
SERVICE REQUEST |
Service type = "signalling" |
|
3a |
Void |
|||
4 |
SS |
The SS starts integrity protection. |
||
5 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
5A0 |
The SS activates UE radio bearer test mode in accordance to [10] TS 34.109, clause 5.2.1 |
|||
5A |
SS |
IF the UE in step 5 set the PDP type to ‘ IPv4′ or in the ACTIVATE PDP CONTEXT REQUEST message then the SS sets the test variable IPtype=’IPv4’ IF the UE in step 4 set the PDP type to ‘IPv4v6’ in the ACTIVATE PDP CONTEXT REQUEST message then the SS allocates an IPv4v6 address. ELSE IF the UE in step 5 set the PDP type to ‘ IPv6′ in the ACTIVATE PDP CONTEXT REQUEST message then the SS sets the test variable IPtype=’IPv6’ |
||
6 |
SS |
The SS establishes the RAB according to reference radio bearer combination 6.10.2.4.1.26 in [9] (1xPS RB 64kbps). |
||
7 |
|
ACTIVATE PDP CONTEXT ACCEPT |
The SS accepts the PDP context. |
|
EXCEPTION: If the test variable is set to ‘IPv6’ then stateless address auto configuration occurs on the user plane bearer established with the ACTIVATE PDP CONTEXT REQUEST message. |
||||
8 |
SS |
The SS initiates a secondary PDP context activation |
||
9 |
|
REQUEST SECONDARY PDP CONTEXT ACTIVATION |
The SS requests a Secondary PDP context activation and starts timer T3385. A UL TFT filter (Packet Filter#1) is configured. |
|
10 |
|
ACTIVATE SECONDARY PDP CONTEXT REQUEST |
The UE requests a Secondary PDP context activation, enters the state PDP-ACTIVE-PENDING and starts timer T3380. NSAPI IE value is different from the value in Step 4. |
|
11 |
SS |
The SS stops timer T3385. The SS reconfigures the RAB according to reference radio bearer combination 6.10.2.4.1.57 in [9] (2xPS RB 64kbps). |
||
12 |
|
ACTIVATE SECONDARY PDP CONTEXT ACCEPT |
The SS accepts the Secondary PDP context activation with the requested QoS |
|
13 |
SS |
The SS waits for T3380 seconds to ensure no further activate request messages come from the UE |
||
14 |
SS |
The SS activates UE test loop mode 4 to establish UE loopback of IP PDUs. See [10] TS 34.109 clause 5.3.2. |
||
15 |
|
IP PDU (IP packet#1) |
The SS transmits IP packet#1 to the UE. IP packet#1 does not match Packet Filter#1. |
|
16 |
|
IP PDU (IP packet#1) |
The SS checks during 1 second that UE transmits IP packet#1 on the radio bearer associated with the primary PDP context. |
|
17 |
|
IP DPU (IP packet#2) |
The SS transmits IP packet#2 to the UE. IP packet#2 matches Packet Filter#1. |
|
18 |
|
IP PDU (IP packet#2) |
The SS checks during 1 second that UE transmits IP packet#2 on the radio bearer associated with the secondary PDP context. |
|
19 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
The SS sends a modify request to UE to add a UL TFT filter (Packet Filter#2) to the secondary PDP context |
|
20 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
The UE accepts the modification request from the SS. |
|
21 |
|
IP PDU (IP packet#3) |
The SS transmits IP packet#3 to the UE. IP packet#3 does not match Packet Filter#1 nor Packet Filter#2. |
|
22 |
|
IP PDU (IP packet#3) |
The SS checks during 1 second that UE transmits IP packet#3 on the radio bearer associated with the primary PDP context. |
|
23 |
|
IP DPU (IP packet#4) |
The SS transmits IP packet#4 to the UE. IP packet#4 matches Packet Filter#1, but not Packet Filter#2. |
|
24 |
|
IP PDU (IP packet#4) |
The SS checks during 1 second that UE transmits IP packet#4 on the radio bearer associated with the secondary PDP context. |
|
25 |
|
IP DPU (IP packet#5) |
The SS transmits IP packet#5 to the UE. IP packet#5 matches Packet Filter#2, but not Packet Filter#1. |
|
26 |
|
IP PDU (IP packet#5) |
The SS checks during 1 second that UE transmits IP packet#5 on the radio bearer associated with the secondary PDP context. |
|
27 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
The SS sends a modify request to UE to remove a UL TFT filter (Packet Filter#1) from the secondary PDP context |
|
28 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
The UE accepts the modification request from the SS. |
|
29 |
|
IP PDU (IP packet#6) |
The SS transmits IP packet#6 to the UE. IP packet#6 matches Packet Filter#1, but not Packet Filter#2. |
|
30 |
|
IP PDU (IP packet#6) |
The SS checks during 1 second that UE transmits IP packet#6 on the radio bearer associated with the primary PDP context. |
|
31 |
|
IP PDU (IP packet#7) |
The SS transmits IP packet#7 to the UE. IP packet#7 matches Packet Filter#2. |
|
32 |
|
IP PDU (IP packet#7) |
The SS checks during 1 second that UE transmits IP packet#7 on the radio bearer associated with the secondary PDP context. |
Specific message contents
Step 7: The IE Protocol Configuration Options is included in this message which has 0005H (Selected Bearer control Mode) set as container identifier in the Additional parameters list. Also, the container identifier contents are set as ‘02’H which means that MS/NW mode is selected.
Step 9: The Linked TI information element in REQUEST SECONDARY PDP CONTEXT ACTIVATION message specifies the TI for the PDP context already activated and is set to the TI value of step 7. The request includes a Bi-directional TFT filter, Packet Filter#1.
Packet Filter#1 is set according to table 11.2.1a.4-1
Step 14: UE test loop mode IE is set to UE test loop mode 4 in the CLOSE UE TEST LOOP message, see [10] TS 34.109 clause 6.2.
Step 15: IP packet#1 is set according to table 11.2.1a.4-2
Step 17: IP packet#2 is set according to table 11.2.1a.4-3
Step 19: Use TI to identify secondary PDP context. Add a packet filter (Packet Filter#2) to the UL TFT.
Packet Filter#2 is set according to table 11.2.1a.4-1
Step 21: IP packet#3 is set identical to IP Packet#1, according to table 11.2.1a.4-2, and does not match Packet Filter#1 nor Packet Filter#2.
Step 23: IP packet#4 is set identical to IP Packet#2, according to table 11.2.1a.4-3, and matches Packet Filter#1 but not Packet Filter#2.
Step 25: IP packet#5 is set according to table 11.2.1a.4-4
Step 27: Use TI to identify secondary PDP context. Remove the packet filter (Packet Filter#1) from the UL TFT.
Step 29: IP packet#6 is set identical to IP Packet#2, according to table 11.2.1a.4-3, and matches Packet Filter#1 but not Packet Filter#2.
Step 31: IP packet#7 is set identical to IP Packet#5, according to table 11.2.1a.4-4, and does not match Packet Filter#1 but matches Packet Filter#2.
Table 11.2.1a.4-1: Packet Filter Table
Packet filter ID |
UL TFT |
Packet filter evaluation precedence |
Protocol Number (IPv4) / Next Header (IPv6) |
Remote address and Subnet mask |
Single Local Port (UE) |
Local Port Range (UE) |
Single Remote Port (NW) |
Remote Port Range (NW) |
IPSec SPI range |
Type of Service (IPv4) / Traffic Class (IPv6) and Mask |
Flow Label (IPv6) |
Comments |
1 |
Secondary PDP Context (Step 9) |
6 |
17 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::] |
60001 |
– |
– |
60350: 60450 |
– |
10101000, Mask= |
– |
UDP application identified by remote address, type of service/traffic class and specific local port number and remote port number range. This is a valid Packet Filter Attribute Combination Type I according to TS 23.060, subclause 15.3.2.0. |
2 |
Secondary PDP Context (Step 19) |
5 |
17 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::] |
60001 |
– |
– |
60350: 60450 |
– |
10100000, Mask= |
– |
Same as packet filter#1 except for “Type of Service(IPv4) / Traffic Class (IPv6)” packet filter component. |
Table 11.2.1a.4-2: IP packet#1 (Step 15, does not match Packet Filter#1)
Derivation path: IETF RFC 791 section 3.1 (IPv4) or RFC 2460 section 3 (IPv6) and RFC 769 introduction |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Type of service (IPv4) / Traffic Class (IPv6) |
10101001 |
Significant for packet filters 1 and 2. Value matches packet filters 1 but not 2. |
|
Protocol |
17 |
UDP Significant for packet filters 1 and 2. Value matches packet filters 1 and 2 |
|
Source Address |
192.168.0.1 |
Not significant for any packet filters |
IPv4 |
Fe80::1:1 |
Not significant for any packet filters |
IPv6 |
|
Destination Address |
172.168.9.1 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 and 2. |
IPv4 |
2001:0bb0:0001:0001 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 and 2. |
IPv6 |
|
Source Port |
60001 |
Significant for packet filter 1. Value matches packet filter 1. |
|
Destination Port |
60350 |
Significant for packet filter 1. Value matches packet filter 1. |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
Table 11.2.1a.4-3: IP packet#2 (Step 17, matches Packet Filter#1)
Derivation path: IP packet#1, Table 11.2.1a.4-2 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Destination Address |
172.168.8.1 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv4 |
2001:0ba0:0001:0001 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv6 |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
Table 11.2.1a.4-4: IP packet#5 (Step 25, matches Packet Filter#2, but not Packet Filter#1)
Derivation path: IP packet#1, Table 11.2.1a.4-2 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Type of service (IPv4) / Traffic Class (IPv6) |
10100000 |
Significant for packet filter 1 and 2. Value matches packet filter 2. Value does not match packet filter 1. |
|
Destination Address |
172.168.8.1 |
Significant for packet filters 1 and 2. Value matches packet filters 1 and 2. |
IPv4 |
2001:0ba0:0001:0001 |
Significant for packet filters 1 and 2. Value matches packet filters 1 and 2. |
IPv6 |
11.2.1a.5 Test requirements
To pass the test the UE shall:
– at step 16 transmit an IP PDU containing IP packet#1 on the radio bearer associated with the primary PDP context.
– at step 18 transmit an IP PDU containing IP packet#2 on the radio bearer associated with the secondary PDP context.
– at step 20 send a MODIFY PDP CONTEXT ACCEPT message.
– at step 22 transmit an IP PDU containing IP packet#3 on the radio bearer associated with the primary PDP context.
– at step 24 transmit an IP PDU containing IP packet#4 on the radio bearer associated with the secondary PDP context.
– at step 26 transmit an IP PDU containing IP packet#5 on the radio bearer associated with the secondary PDP context.
– at step 28 send a MODIFY PDP CONTEXT ACCEPT message.
– at step 30 transmit an IP PDU containing IP packet#6 on the radio bearer associated with the primary PDP context.
– at step 32 transmit an IP PDU containing IP packet#7 on the radio bearer associated with the secondary PDP context.
11.2.1b Network initiated PDP context modification / Adding filters to TFT of the Primary PDP context
11.2.1b.1 Definition
11.2.1b.2 Conformance requirement
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 modified packet filters in the TFT information element that shall be applied to that specific PDP context.
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.
Upon receipt of the MODIFY PDP CONTEXT REQUEST message the MS shall 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.
…
Each valid downlink- and uplink-packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique among all packet filters for the same direction (downlink or uplink) for one PDP address and APN pair, and at least one of the following attributes:
– Remote Address and Subnet Mask.
– Protocol Number (IPv4) / Next Header (IPv6).
– Local Port Range.
– Remote Port Range.
– IPSec Security Parameter Index (SPI).
– Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask.
– Flow Label (IPv6).
In the list of attributes above ‘Remote’ refers to the external network entity, and ‘Local’ to the MS.
Some of the above-listed attributes may coexist in a packet filter while others mutually exclude each other. In table 12 below, the possible combinations are shown. Only those attributes marked with an "X" may be specified for a single packet filter. All marked attributes may be specified, but at least one shall be specified.
If the parameters of the header of a received PDP PDU match all specified attribute values in a packet filter, then it is considered that a match is found for this packet filter. In this case, the evaluation procedure is aborted. Other packet filters in increasing order of their evaluation precedence index are evaluated until such match is found.
There may be potential conflicts if attribute values are combined in such a way that the defined filter can never achieve a match to a valid IP packet header. However, the determination of such conflicts is outside the scope of GPRS standardization.
Table 12: Valid Packet Filter Attribute Combinations
Valid combination types |
|||
Packet filter attribute |
I |
II |
III |
Remote Address and Subnet Mask |
X |
X |
X |
Protocol Number (IPv4) / Next Header (IPv6) |
X |
X |
|
Local Port Range |
X |
||
Remote Port Range |
X |
||
IPSec SPI |
X |
||
TOS (IPv4) / Traffic Class (IPv6) and Mask |
X |
X |
X |
Flow Label (IPv6) |
X |
Reference
3GPP TS 24.008 clauses 6.1.3.3 and 6.1.3.3.1. 3GPP TS 23.060 clause 15.3.2.0.
11.2.1b.3 Test purpose
1. To verify that the UE, when having a secondary PDP context active, successfully performs network initiated PDP context modification procedure to add a filter to the TFT of the primary PDP context.
2. To verify that the UE successfully performs packet filtering before and after adding the filter to the primary PDP context.
11.2.1b.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– Method of activating a PDP context
– Support of automatic PS attach procedure at switch on yes/no
Test procedure
A PDP context activation is requested by the user and accepted by the SS.
If the UE set the PDP type to ‘IPv4’ or in the ACTIVATE PDP CONTEXT REQUEST then the SS allocates a IPv4 address to the UE and set the test variable IP type to “IPv4”. If the UE sets the PDP type to IPv4v6 in the ACTIVATE PDP CONTEXT then the SS allocates an IPv4v6 address to the UE.
Else if the UE set the PDP type to ‘IPv6’ in the ACTIVATE PDP CONTEXT REQUEST then the SS allocates an IPv6 address via stateless address auto configuration on the established primary PDP context and set the test variable IP type to “IPv6”. A secondary PDP context activation with a UL TFT filter (Packet Filter#1) is requested by the SS and the activation procedure is completed by the UE.
The SS activates UE test loop mode 4 and transmits two IP Packets to the UE, IP packet#1 and IP packet#2. IP packet#1 does not match Packet Filter#1. IP packet#2 matches Packet Filter#1. The SS checks that IP packet#1 is returned by the UE on the radio bearer associated with the primary PDP context and IP packet#2 is returned by the UE on the radio bearer associated with the secondary PDP context. The SS sends a MODIFY PDP CONTEXT REQUEST message to the UE requesting a new TFT filter to be added to the primary PDP context (Packet Filter#2, having a higher evaluation precedence index than Packet Filter#1 and will be evaluated after Packet Filter#1). The UE sends a MODIFY PDP CONTEXT ACCEPT message in return.
The SS transmits four IP Packets to the UE, IP packet#3; IP packet#4; IP packet#5 and IP packet#6. IP packet#3 matches Packet Filter#2, but not Packet Filter#1. IP packet#4 matches Packet Filter#1, but not Packet Filter#2. IP packet#5 matches both Packet Filter#1 and Packet Filter#2. IP packet #6 does not match Packet Filter #1 or Packet Filter #2. The SS checks that IP packet#3 is returned by the UE on the radio bearer associated with the primary PDP context. The SS checks that IP packet#4 and IP packet#5 is returned by the UE on the radio bearer associated with the secondary PDP context (see Note). The SS checks that IP packet#6 is not returned by the UE. Note IP packet#5 is matching both Packet Filter#1 and Packet Filter#2. As the packet filter evaluation precedence index is lower for Packet Filter#1, and will be evaluated before Packet Filter#2 then shall IP packet#5 be returned by the UE on the radio bearer associated with Packet Filter#1 (secondary PDP context).
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
SS |
The SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to either Originating Streaming Call, Originating Interactive Call or Originating Background Call or OriginatingSubscribedTrafficCall |
||
2 |
SS |
|||
3 |
|
SERVICE REQUEST |
Service type = "signalling" |
|
3a |
Void |
|||
4 |
SS |
The SS starts integrity protection. |
||
5 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
5A0 |
The SS activates UE radio bearer test mode in accordance to [10] TS 34.109, clause 5.2.1 |
|||
5A |
SS |
IF the UE in step 5 set the PDP type to ‘ IPv4′ or in the ACTIVATE PDP CONTEXT REQUEST message then the SS sets the test variable IPtype=’IPv4’ IF the UE in step 4 set the PDP type to ‘IPv4v6’ in the ACTIVATE PDP CONTEXT REQUEST message then the SS allocates an IPv4v6 address. ELSE IF the UE in step 5 set the PDP type to ‘ IPv6′ in the ACTIVATE PDP CONTEXT REQUEST message then the SS sets the test variable IPtype=’IPv6’ |
||
6 |
SS |
The SS establishes the RAB according to reference radio bearer combination 6.10.2.4.1.57 in [9] (1xPS RB 64kbps). |
||
7 |
|
ACTIVATE PDP CONTEXT ACCEPT |
The SS accepts the PDP context. |
|
EXCEPTION: If the test variable is set to ‘IPv6’ then stateless address auto configuration occurs on the user plane bearer established with the ACTIVATE PDP CONTEXT REQUEST message |
||||
8 |
SS |
The SS initiates a secondary PDP context activation |
||
9 |
|
REQUEST SECONDARY PDP CONTEXT ACTIVATION |
The SS requests a Secondary PDP context activation and starts timer T3385. |
|
10 |
|
ACTIVATE SECONDARY PDP CONTEXT REQUEST |
The UE requests a Secondary PDP context activation, enters the state PDP-ACTIVE-PENDING and starts timer T3380. NSAPI IE value is different from the value in Step 4. A UL TFT filter (Packet Filter#1) is configured. |
|
11 |
SS |
The SS stops timer T3385. The SS reconfigures the RAB according to reference radio bearer combination 6.10.2.4.5.5a in [9] (2xPS RB 64kbps). |
||
12 |
|
ACTIVATE SECONDARY PDP CONTEXT ACCEPT |
The SS accepts the Secondary PDP context activation with the requested QoS |
|
13 |
SS |
The SS waits for T3380 seconds to ensure no further activate request messages come from the UE |
||
14 |
SS |
The SS activates UE test loop mode 4 to establish UE loopback of IP PDUs. See [10] TS 34.109 clause 5.3.2. |
||
15 |
|
IP PDU (IP packet#1) |
The SS transmits IP packet#1 to the UE. IP packet#1 does not match Packet Filter#1. |
|
16 |
|
IP PDU (IP packet#1) |
The SS checks during 1 second that UE transmits IP packet#1 on the radio bearer associated with the primary PDP context. |
|
17 |
|
IP DPU (IP packet#2) |
The SS transmits IP packet#2 to the UE. IP packet#2 matches Packet Filter#1. |
|
18 |
|
IP PDU (IP packet#2) |
The SS checks during 1 second that UE transmits IP packet#2 on the radio bearer associated with the secondary PDP context. |
|
19 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
The SS sends a modify request to UE to add a UL TFT filter (Packet Fileter#2) for primary PDP context |
|
20 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
The UE accepts the modification request from the SS. |
|
21 |
|
IP PDU (IP packet#3) |
The SS transmits IP packet#3 to the UE. IP packet#3 matches Packet Filter#2, but not Packet Filter#1. |
|
22 |
|
IP PDU (IP packet#3) |
The SS checks during 1 second that UE transmits IP packet#1 on the radio bearer associated with the primary PDP context. |
|
23 |
|
IP DPU (IP packet#4) |
The SS transmits IP packet#4 to the UE. IP packet#4 matches Packet Filter#1, but not Packet Filter#2. |
|
24 |
|
IP PDU (IP packet#4) |
The SS checks during 1 second that UE transmits IP packet#4 on the radio bearer associated with the secondary PDP context. |
|
25 |
|
IP DPU (IP packet#5) |
The SS transmits IP packet#5 to the UE. IP packet#5 matches both Packet Filter#1 and Packet Filter#2. |
|
26 |
|
IP PDU (IP packet#5) |
The SS checks during 1 second that UE transmits IP packet#5 on the radio bearer associated with the secondary PDP context. |
|
27 |
|
IP DPU (IP packet#6) |
The SS transmits IP packet#6 to the UE. . IP packet #6 does not match Packet Filter #1 or Packet Filter #2. |
|
28 |
SS |
The SS checks during 1 second that UE do not transmit IP packet#6. |
Specific message contents
Step 7: The IE Protocol Configuration Options is included in this message which has 0005H (Selected Bearer control Mode) set as container identifier in the Additional parameters list. Also, the container identifier contents are set as ‘02’H which means that MS/NW mode is selected.
For details please refer to 24.008 Sec 10.5.6.3.
Step 9: The Linked TI information element in REQUEST SECONDARY PDP CONTEXT ACTIVATION message specifies the TI for the PDP context already activated and is set to the TI value of step 7. The request includes a Bi-directional TFT filter, Packet Filter#1.
Packet Filter#1 is set according to table 11.2.1b.4-1
Step 14: UE test loop mode IE is set to UE test loop mode 4 in the CLOSE UE TEST LOOP message, see [10] TS 34.109 clause 6.2.
Step 15: IP packet#1 is set according to table 11.2.1b.4-2
Step 17: IP packet#2 is set according to table 11.2.1b.4-3
Step 19: Use TI to identify primary PDP context. Add a packet filter (Packet Filter#2) to the UL TFT.
Packet Filter#2 is set according to table 11.2.1b.4-1
Step 21: IP packet#3 is set according to table 11.2.1b.4-4
Step 23: IP packet#4 is set according to table 11.2.1b.4-5
Step 25: IP packet#5 is set identical to IP Packet#2, according to table 11.2.1b.4-3, and matches both Packet Filter#1 and Packet Filter#2
Step 27: IP packet#6 is set identical to IP Packet#1, according to table 11.2.1b.4-2, and does not match Packet Filter #1 or Packet Filter #2
Table 11.2.1b.4-1: Packet Filter Table
Packet filter ID |
UL TFT |
Packet filter evaluation precedence |
Protocol Number (IPv4) / Next Header (IPv6) |
Remote address and Subnet mask |
Single Local Port (UE) |
Local Port Range (UE) |
Single Remote Port (NW) |
Remote Port Range (NW) |
IPSec SPI range |
Type of Service (IPv4) / Traffic Class (IPv6) and Mask |
Flow Label (IPv6) |
Comments |
1 |
Secondary PDP Context (Step 9) |
1 |
17 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::] |
60001 |
– |
– |
60350: 60450 |
– |
10101000, Mask= |
– |
UDP application identified by remote address, type of service/traffic class and specific local and remote port numbers. This is a valid Packet Filter Attribute Combination Type I according to TS 23.060, subclause 15.3.2.0. |
2 |
Primary PDP Context (Step 19) |
2 |
17 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::] |
– |
60000:60100 |
60350 |
– |
– |
10101000, Mask= |
– |
UDP application identified by remote address, type of service/traffic class and local port numbers and single remote port. This is a valid Packet Filter Attribute Combination Type I according to TS 23.060, subclause 15.3.2.0. |
Table 11.2.1b.4-2: IP packet#1 (step 15, does not match Packet Filter#1)
Derivation path: IETF RFC 791 section 3.1 (IPv4) or RFC 2460 section 3 (IPv6) and RFC 769 introduction |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Type of service (IPv4) / Traffic Class (IPv6) |
10101001 |
Significant for packet filters 1 and 2. Value matches packet filters 1 and 2. |
|
Protocol |
17 |
UDP Significant packet filters 1. Value matches packet filters 1 and 2. |
|
Source Address |
192.168.0.1 |
Not significant for any packet filters |
IPv4 |
Fe80::1:1 |
Not significant for any packet filters |
IPv6 |
|
Destination Address |
172.168.9.1 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 and 2. |
IPv4 |
2001:0bb0:0001:0001 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 and 2. |
IPv6 |
|
Source Port |
60001 |
Significant for packet filter 1. Value matches packet filters 1 and 2. |
|
Destination Port |
60350 |
Significant for packet filter 1. . Value matches packet filters 1 and 2. |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
Table 11.2.1b.4-3: IP packet#2 (step 17, matches Packet Filter#1)
Derivation path: IP packet#1, Table 11.2.1b.4-2 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Destination Address |
172.168.8.1 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv4 |
2001:0ba0:0001:0001 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv6 |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
Table 11.2.1b.4-4: IP packet#3 (step 21, matches Packet Filter#2 but not Packet Filter#1)
Derivation path: IP packet#1, Table 11.2.1b.4-2 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Destination Address |
172.168.8.1 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv4 |
2001:0ba0:0001:0001 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv6 |
|
Source Port |
60002 |
Significant for packet filter 1 and 2. Value matches packet filter 2. Value does not match packet filter 1 |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
Table 11.2.1b.4-5: IP packet#4 (step 23, matches Packet Filter#1 but not Packet Filter#2)
Derivation path: IP packet#1, Table 11.2.1b.4-2 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
Destination Address |
172.168.8.1 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv4 |
2001:0ba0:0001:0001 |
Significant for packet filter 1 and 2. Value matches packet filters 1 and 2. |
IPv6 |
|
Destination Port |
60351 |
Significant for packet filter 1 and 2. Value matches packet filter 1. Value does not match packet filter 2. |
Condition |
Explanation |
IPv4 |
This condition applies if test variable IP type is set to ‘IPv4’. |
IPv6 |
This condition applies if test variable IP type is set to ‘IPv6’. |
11.2.1b.5 Test requirements
To pass the test the UE shall:
– at step 16 transmit an IP PDU containing IP packet#1 on the radio bearer associated with the primary PDP context.
– at step 18 transmit an IP PDU containing IP packet#2 on the radio bearer associated with the secondary PDP context.
– at step 20 send a MODIFY PDP CONTEXT ACCEPT message.
– at step 22 transmit an IP PDU containing IP packet#3 on the radio bearer associated with the primary PDP context.
– at step 24 transmit an IP PDU containing IP packet#4 on the radio bearer associated with the secondary PDP context.
– at step 26 transmit an IP PDU containing IP packet#5 on the radio bearer associated with the secondary PDP context.
– at step 28 not transmit and IP PDU.
11.2.2 UE initiated PDP context modification
11.2.2.1 UE initiated PDP Context Modification accepted by network
11.2.2.1.1 Definition
None
11.2.2.1.2 Conformance requirement
In order to initiate the procedure, the UE 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 GSM).
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 GSM by the logical link.
Upon receipt of the MODIFY PDP CONTEXT ACCEPT message, the UE shall stop the timer T3381. If the offered QoS parameters received from the network differs from the QoS requested by the UE, the UE shall either accept the negotiated QoS or initiate the PDP context deactivation procedure.
Reference
3GPP TS 24.008 clauses 6.1.3.3 and 6.1.3.3.2.
11.2.2.1.3 Test purpose
To test the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT ACCEPT message from the SS with
– Requested QoS;
11.2.2.1.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– PS Supported yes/no
– Method of setting minimum QoS
– Method of activating a PDP context
Test procedure
The requested QoS is set. A PDP context is activated by the user and accepted by the SS. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT REQUEST message with new QoS. The SS accepts the context modification and replies with the MODIFY PDP CONTEXT ACCEPT message with the QoS requested. The SS waits ‘T3390’ seconds to confirm that UE will not initiate a PDP context deactivation.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request the modification of a PDP context, with new QoS |
|
5 |
|
MODIFY PDP CONTEXT ACCEPT (NETWORK TO UE DIRECTION) |
Accept the PDP context modification with QoS requested |
|
6 |
SS |
SS waits ‘T3390’ seconds to confirm UE does not initiate PDP context deactivation. |
||
7 |
Void |
|||
8 |
Void |
|||
9 |
Void |
|||
10 |
Void |
|||
11 |
Void |
Specific message contents
None.
11.2.2.1.5 Test requirements
When requesting the PDP context modification, the UE shall:
– Modify the PDP context if SS replied with the requested QoS;
11.2.2.2 UE initiated PDP Context Modification not accepted by the network
11.2.2.2.1 Definition
11.2.2.2.2 Conformance requirement
In order to initiate the procedure, the UE 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 GSM).
Upon receipt of a MODIFY PDP CONTEXT REQUEST message, the network may reject the UE initiated PDP context modification request by sending a MODIFY PDP CONTEXT REJECT message to the UE. 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 the SM cause value is #26 "insufficient resources", the network may include a value for timer T3396 value IE in the MODIFY PDP CONTEXT REJECT message.
Upon receipt of a MODIFY PDP CONTEXT REJECT message, the UE shall stop timer T3381 and enter the state PDP-ACTIVE.
If the SM cause value is #26 and T3396 value IE is included:
– the MS takes different actions depending on the timer value received for T3396 value IE:
i) if the timer value of T3396 value IE indicates neither zero nor deactivated, the MS shall start timer T3396 and not try to send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST messages for the same APN until timer T3396 expires, the timer T3396 is stopped, 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 try to send another ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST messages for the same APN until the MS is switched off or the SIM/USIM is removed or the MS receives REQUEST PDP CONTEXT ACTIVATION or REQUEST SECONDARY PDP CONTEXT ACTIVATION or MODIFY PDP CONTEXT REQUEST message for the same APN from the network; or
iii) if the timer value indicates that this timer is zero, the MS may send an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST messages for the same APN.
If the T3396 value IE is not included, the MS may send an ACTIVATE PDP CONTEXT REQUEST, ACTIVATE SECONDARY PDP CONTEXT REQUEST or MODIFY PDP CONTEXT REQUEST messages for the same APN.
Reference
3GPP TS 24.008 clauses 6.1.3.3, 6.1.3.3.2 and 6.1.3.3.3.
11.2.2.2.3 Test purpose
To test the behaviour of the UE upon receipt of a MODIFY PDP CONTEXT REJECT message from the System Simulator.
11.2.2.2.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– PS Supported yes/no
– Method of activating a PDP context
Test procedure
A PDP context is activated by the user and accepted by the SS. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT REQUEST message. The SS rejects the context modification and replies with the MODIFY PDP CONTEXT REJECT with cause set to # 26: insufficient resources and a valid timer T3396 value IE.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
1a |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to either Originating Streaming Call, Originating Interactive Call or Originating Background Call or OriginatingSubscribedTrafficCall |
||
1b |
|
SERVICE REQUEST |
||
1c |
SS |
The SS starts ciphering and integrity protection. |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
2a |
SS |
The SS establishes the RAB |
||
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
The UE requests modification of the PDP context and starts timer T3381 |
|
5 |
|
MODIFY PDP CONTEXT REJECT |
The SS rejects PDP context modification, SM cause = #26 |
|
5a |
The UE starts T3396 |
|||
6 |
SS |
Wait for T3396 expiry to ensure no further MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) messages are sent by the UE |
Specific message contents
MODIFY PDP CONTEXT REJECT (step 5)
Information Element |
Value/remark |
SM cause |
#26: insufficient resources |
T3396 value |
60s |
11.2.2.2.5 Test requirements
After receiving MODIFY PDP CONTEXT REJECT message from the SS, the UE shall not resend PDP context modification request before the expiry of T3396.
11.2.2.3 UE initiated PDP Context Modification / Dual priority / low priority override
11.2.2.3.1 Definition
Void
11.2.2.3.2 Conformance requirement
An MS configured for NAS signalling low priority (see 3GPP TS 24.368 [135], 3GPP TS 31.102 [112]) indicates this by including the Device properties IE in the appropriate NAS message and setting the low priority indicator to "MS is configured to NAS signalling low priority" except for the following cases in which the MS shall set the low priority indicator to "MS is not configured for NAS signalling low priority":
– the MS is performing an attach for emergency bearer services;
– the MS has a PDN connection for emergency bearer services established and is performing mobility management procedures, or is establishing a PDN connection for emergency bearer services;
– the MS configured for dual priority is requested by the upper layers to establish a PDN connection with the low priority indicator set to "MS is not configured for NAS signalling low priority";
– the MS configured for dual priority is performing EPS session management procedures related to the PDN connection established with low priority indicator set to "MS is not configured for NAS signalling low priority";
– the MS configured for dual priority has a PDN connection established by setting the low priority indicator to "MS is not configured for NAS signalling low priority" and is performing EPS mobility management procedures;
– the MS is accessing the network with access class 11 – 15; or
– the MS is responding to paging.
The network may use the NAS signalling low priority indication for NAS level mobility management congestion control on a per core network node basis and APN based congestion control.
If the NAS signalling low priority indication is provided in an ACTIVATE PDP CONTEXT REQUEST message, the SGSN stores the NAS signalling low priority indication within the default PDP context activated due to this request.
Reference
3GPP TS 24.008 clauses 1.8.
11.2.2.3.3 Test purpose
To verify that a MS configured for dual priority set the low priority indicator to "MS is not configured for NAS signalling low priority" when requested by the upper layers to establish a PDP context with the low priority indicator overridden
To verify that a MS configured for dual priority set the low priority indicator to "MS is not configured for NAS signalling low priority" when it is performing session management procedures related to the PDP context established with low priority indicator set to "MS is not configured for NAS signalling low priority"
11.2.2.3.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
The UE is configured for NAS signalling low priority
The UE is configured for NAS signalling low priority override
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value |
EFUST |
Service 96 is supported. |
EFNASCONFIG |
“NAS_SignallingPriority is set to “NAS signalling low priority” “Override_NAS_SignallingLowPriority” is set to 1, as defined in TS 24.368, clause 5.3. “ExtendedAccessBarring is set to 1 which indicate the extended access barring is applied for the UE” as defined in TS 24.368, clause 5.8. OverrideExtendedAccessBarring is set to 1 which indicate the Override extended access barring is applied for the UE” as defined in TS 24.368, clause 5.10 |
Related ICS/IXIT statements
Support of PS service Yes/No
Method of activating a PDP context Yes/No
Test procedure
A PDP context is activated by the user, indicating that the UE is not configured for NAS signalling low priority, and accepted by the SS. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT REQUEST message, indicating that the UE is not configured for NAS signalling low priority. The SS accepts the context modification and replies with the MODIFY PDP CONTEXT ACCEPT. The SS waits ‘T3390’ seconds to confirm that UE will not initiate a PDP context deactivation.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context Device properties = ‘MS is not configured for NAS signalling low priority’ |
|
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request the modification of a PDP context Device properties = ‘MS is not configured for NAS signalling low priority’ |
|
5 |
|
MODIFY PDP CONTEXT ACCEPT (NETWORK TO UE DIRECTION) |
Accept the PDP context modification with |
|
6 |
SS |
SS waits ‘T3390’ seconds to confirm UE does not initiate PDP context deactivation. |
Specific message contents
None.
11.2.2.3.5 Test requirements
Step 2: ACTIVATE PDP CONTEXT REQUEST message contains the Device properties IE set to ‘MS is not configured for NAS signalling low priority’.
Step 4: MODIFY PDP CONTEXT REQUEST message contains the Device properties IE set to ‘MS is not configured for NAS signalling low priority’.
11.2.3 Abnormal cases
11.2.3.1 T3381 Expiry
11.2.3.1.1 Definition
11.2.3.1.2 Conformance requirement
On the first expiry of timer T3381, the UE shall re-send 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 UE may continue to use the previously negotiated QoS or it may initiate the PDP context deactivation procedure.
Reference
3GPP TS 24.008 clause 6.1.3.3.4 a) case: In the UE.
11.2.3.1.3 Test purpose
To test the behaviour of the UE when SS does not reply to MODIFY PDP CONTEXT REQUEST message.
11.2.3.1.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– PS Supported yes/no
– Method of activating a PDP context
Test procedure
A PDP context activation is requested by the user and accepted by the SS. The UE shall send MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) message five times with T3381 seconds between each message. After this no further MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) messages shall be sent by the UE.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
1a |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to either Originating Streaming Call, Originating Interactive Call or Originating Background Call or OriginatingSubscribedTrafficCall |
||
1b |
|
SERVICE REQUEST |
||
1c |
SS |
The SS starts ciphering and integrity protection. |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
2a |
SS |
The SS establishes the RAB |
||
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context activation |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context, with new QoS |
|
5 |
SS |
T3381 seconds |
||
6 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context, with the same QoS as in step 4 |
|
7 |
SS |
T3381 seconds |
||
8 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context, with the same QoS as in step 4 |
|
9 |
SS |
T3381 seconds |
||
10 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context, with the same QoS as in step 4 |
|
11 |
SS |
T3381 seconds |
||
12 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context, with the same QoS as in step 4 |
|
13 |
SS |
Wait for T3381 seconds to ensure no further MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) messages are sent by the UE |
Specific message contents
None.
11.2.3.1.5 Test requirements
UE shall re-send the MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) to SS five times in order to initiate the PDP context modification, with expiry of timer T3381 between messages. After fifth try, UE shall send no more MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) messages to SS.
11.2.3.2 Collision of UE and network initiated PDP context modification procedures
11.2.3.2.1 Definition
11.2.3.2.2 Conformance requirement
A collision of a UE and network initiated PDP context modification procedures is identified by the UE if a MODIFY PDP CONTEXT REQUEST message is received from the network after the UE has sent a MODIFY PDP CONTEXT REQUEST message itself, and both messages contain the same TI and the UE 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 modification shall take precedence over the UE initiated PDP context modification. The UE shall terminate internally the UE 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.
Reference
3GPP TS 24.008 clause 6.1.3.3.4 b).
11.2.3.2.3 Test purpose
To test behaviour of the UE when it identifies collision of the UE and SS initiated PDP context modification with the same TI.
11.2.3.2.4 Method of test
Initial conditions
System Simulator:
1 cell, default parameters.
User Equipment:
The UE is in GMM-state "GMM-REGISTERED, normal service" with valid P-TMSI and CKSN.
Related ICS/IXIT statements
– PS Supported yes/no
– Method of activating a PDP context
Test procedure
A PDP context is activated by the user and accepted by the SS. The UE initiates a PDP context modification by sending a MODIFY PDP CONTEXT REQUEST message. Then the SS initiates the PDP context modification by sending MODIFY PDP CONTEXT REQUEST message with the same TI. The UE shall reply to the SS initiated PDP context modification procedure by sending MODIFY PDP CONTEXT ACCEPT message with the same TI.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
Initiate a PDP context activation |
||
1a |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to either Originating Conversational Call, Originating Streaming Call, Originating Interactive Call, Originating Background Call, or Originating Subscribed traffic call |
||
1b |
|
SERVICE REQUEST |
||
1c |
SS |
The SS starts ciphering and integrity protection. |
||
2 |
|
ACTIVATE PDP CONTEXT REQUEST |
Activate a PDP context |
|
2a |
SS |
The SS establishes the RAB. |
||
3 |
|
ACTIVATE PDP CONTEXT ACCEPT |
Accept the PDP context activation |
|
4 |
|
MODIFY PDP CONTEXT REQUEST (UE TO NETWORK DIRECTION) |
Request modification of the PDP context |
|
5 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
Request modification of the PDP context with the same TI |
|
6 |
UE |
UE identifies collision, terminates internally the UE initiated PDP context modification procedure |
||
7 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
Accept SS initiated PDP context modification |
Specific message contents
Steps 2, 4 and 7. TI flag (bit 8) in the TI IE is set to 0 (transaction initiated by the UE).
Steps 3 and 5. TI flag (bit 8) in the TI IE is set to 1.
Steps 2, 3, 4, 5 and 7. The value of the TIO (bits 5-7) in the TI IE is the same in these test steps.
11.2.3.2.5 Test requirements
In step 6, the UE shall terminate internally the UE initiated PDP context modification procedure and proceed with SS initiated PDP context modification.