11.9 UE routing of uplink packets
34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification
11.9.1 UE routing of uplink packets
11.9.1.1 Definition
11.9.1.2 Conformance requirement
References: The conformance requirements covered in the present TC are specified in: TS 23.060, clause 15.3.2.0 and TS 24.008, clause 10.5.6.12.
[TS 23.060, clause 15.3.2.0]
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 |
||
[TS 24.008, clause 10.5.6.12]
The purpose of the traffic flow template information element is to specify the TFT parameters and operations for a PDP context. In addition, this information element may be used to transfer extra parameters to the network (e.g. the Authorization Token; see 3GPP TS 24.229 [95]). The TFT may contain packet filters for the downlink direction, the uplink direction or packet filters that apply for both directions. The packet filters determine the traffic mapping to PDP contexts. The downlink packet filters shall be applied by the network and the uplink packet filters shall be applied by the MS. A packet filter that applies for both directions shall be applied by the network as a downlink packet filter and by the MS as an uplink filter.
The traffic flow template is a type 4 information element with a minimum length of 3 octets. The maximum length for the IE is 257 octets.
NOTE 1: The IE length restriction is due to the maximum length that can be encoded in a single length octet.
NOTE 2: A maximum size IPv4 packet filter can be 32 bytes. Therefore, 7 maximum size IPv4 type packet filters, plus the last packet filter which can contain max 30 octets can fit into one TFT, i.e. if needed not all packet filter components can be defined into one message. A maximum size Ipv6 packet filter can be 60 bytes. Therefore, only 4 maximum size IPv6 packet filters can fit into one TFT. However, using "Add packet filters to existing TFT", it’s possible to create a TFT including 16 maximum size Ipv4 or IPv6 filters.
The traffic flow template information element is coded as shown in figure 10.5.144/3GPP TS 24.008 and table 10.5.162/3GPP TS 24.008.
|
8 7 6 5 4 3 2 1 |
||||
|
Traffic flow template IEI |
Octet 1 |
|||
|
Length of traffic flow template IE |
Octet 2 |
|||
|
TFT operation code |
E bit |
Number of packet filters |
Octet 3 |
|
|
Packet filter list |
Octet 4 Octet z |
|||
|
Parameters list |
Octet z+1 Octet v |
|||
Figure 10.5.144/3GPP TS 24.008: Traffic flow template information element
|
8 7 6 5 4 3 2 1 |
||
|
Packet filter identifier 1 |
Octet 4 |
|
|
Packet filter identifier 2 |
Octet 5 |
|
|
… |
||
|
Packet filter identifier N |
Octet N+3 |
Figure 10.5.144a/3GPP TS 24.008: Packet filter list when the TFT operation is "delete packet filters from existing TFT" (z=N+3)
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
Packet filter identifier 1 |
Octet 4 |
||||||||
|
Packet filter evaluation precedence 1 |
Octet 5 |
||||||||
|
Length of Packet filter contents 1 |
Octet 6 |
||||||||
|
Packet filter contents 1 |
Octet 7 Octet m |
||||||||
|
Packet filter identifier 2 |
Octet m+1 |
||||||||
|
Packet filter evaluation precedence 2 |
Octet m+2 |
||||||||
|
Length of Packet filter contents 2 |
Octet m+3 |
||||||||
|
Packet filter contents 2 |
Octet m+4 Octet n |
||||||||
|
… |
Octet n+1 Octet y |
||||||||
|
Packet filter identifier N |
Octet y+1 |
||||||||
|
Packet filter evaluation precedence N |
Octet y+2 |
||||||||
|
Length of Packet filter contents N |
Octet y+3 |
||||||||
|
Packet filter contents N |
Octet y+4 Octet z |
||||||||
Figure 10.5.144b/3GPP TS 24.008: Packet filter list when the TFT operation is "create new TFT", or "add packet filters to existing TFT" or "replace packet filters in existing TFT"
|
8 |
7 |
6 |
5 |
4 |
3 |
2 |
1 |
||
|
Parameter identifier 1 |
Octet z+1 |
||||||||
|
Length of Parameter contents 1 |
Octet z+2 |
||||||||
|
Parameter contents 1 |
Octet z+3 Octet k |
||||||||
|
Parameter identifier 2 |
Octet k+1 |
||||||||
|
Length of Parameter contents 2 |
Octet k+2 |
||||||||
|
Parameter contents 2 |
Octet k+3 Octet p |
||||||||
|
… |
Octet p+1 Octet q |
||||||||
|
Parameter identifier N |
Octet q+1 |
||||||||
|
Length of Parameter contents N |
Octet q+2 |
||||||||
|
Parameter contents N |
Octet q+3 Octet v |
||||||||
Figure 10.5.144c/3GPP TS 24.008: Parameters list
Table 10.5.162/3GPP TS 24.008: Traffic flow template information element
|
TFT operation code (octet 3) 0 0 0 Spare 0 1 0 Delete existing TFT 0 1 1 Add packet filters to existing TFT 1 0 0 Replace packet filters in existing TFT 1 0 1 Delete packet filters from existing TFT 1 1 1 Reserved The TFT operation code "No TFT operation" shall be used if a parameters list is included but no packet filter list is included in the traffic flow template information element. E bit (bit 5 of octet 3) The E bit indicates if a parameters list is included in the TFT IE and it is encoded as follows: 0 parameters list is not included 1 parameters list is included Number of packet filters (octet 3) The number of packet filters contains the binary coding for the number of packet filters in the packet filter list. The number of packet filters field is encoded in bits 4 through 1 of octet 3 where bit 4 is the most significant and bit 1 is the least significant bit. For the "delete existing TFT" operation and for the "no TFT operation", the number of packet filters shall be coded as 0. For all other operations, the number of packet filters shall be greater than 0 and less than or equal to 16. Packet filter list (octets 4 to z) The packet filter list contains a variable number of packet filters. For the "delete existing TFT" operation and the "no TFT operation", the packet filter list shall be empty. For the "delete packet filters from existing TFT" operation, the packet filter list shall contain a variable number of packet filter identifiers. This number shall be derived from the coding of the number of packet filters field in octet 3. For the "create new TFT", "add packet filters to existing TFT" and "replace packet filters in existing TFT" operations, the packet filter list shall contain a variable number of packet filters. This number shall be derived from the coding of the number of packet filters field in octet 3. Each packet filter is of variable length and consists of – a packet filter identifier and direction (1 octet); – the length of the packet filter contents (1 octet); and The packet filter identifier field is used to identify each packet filter in a TFT. The least significant 4 bits are used. The packet filter direction is used to indicate, in bits 5 and 6, for what traffic direction the filter applies: 00 – pre Rel-7 TFT filter Bits 8 through 7 are spare bits. The packet filter evaluation precedence field is used to specify the precedence for the packet filter among all packet filters in all TFTs associated with this PDP address. Higher the value of the packet filter evaluation precedence field, lower the precedence of that packet filter is. The first bit in transmission order is the most significant bit. The length of the packet filter contents field contains the binary coded representation of the length of the packet filter contents field of a packet filter. The first bit in transmission order is the most significant bit. The packet filter contents field is of variable size and contains a variable number (at least one) of packet filter components. Each packet filter component shall be encoded as a sequence of a one octet packet filter component type identifier and a fixed length packet filter component value field. The packet filter component type identifier shall be transmitted first. In each packet filter, there shall not be more than one occurrence of each packet filter component type. Among the "IPv4 remote address type" and "IPv6 remote address type" packet filter components, only one shall be present in one packet filter. Among the "single local port type" and "local port range type" packet filter components, only one shall be present in one packet filter. Among the "single remote port type" and "remote port range type" packet filter components, only one shall be present in one packet filter. The term local refers to the MS and the term remote refers to an external network entity. Packet filter component type identifier 0 0 0 1 0 0 0 0 IPv4 remote address type All other values are reserved. For "IPv4 remote address type", the packet filter component value field shall be encoded as a sequence of a four octet IPv4 address field and a four octet IPv4 address mask field. The IPv4 address field shall be transmitted first. For "IPv6 remote address type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and a sixteen octet IPv6 address mask field. The IPv6 address field shall be transmitted first. For "Protocol identifier/Next header type", the packet filter component value field shall be encoded as one octet which specifies the IPv4 protocol identifier or IPv6 next header. For "Single local port type" and "Single remote port type", the packet filter component value field shall be encoded as two octet which specifies a port number. For "Local port range type" and "Remote port range type", the packet filter component value field shall be encoded as a sequence of a two octet port range low limit field and a two octet port range high limit field. The port range low limit field shall be transmitted first. For "Security parameter index", the packet filter component value field shall be encoded as four octet which specifies the IPSec security parameter index. For "Type of service/Traffic class type", the packet filter component value field shall be encoded as a sequence of a one octet Type-of-Service/Traffic Class field and a one octet Type-of-Service/Traffic Class mask field. The Type-of-Service/Traffic Class field shall be transmitted first. For "Flow label type", the packet filter component value field shall be encoded as three octet which specifies the IPv6 flow label. The bits 8 through 5 of the first octet shall be spare whereas the remaining 20 bits shall contain the IPv6 flow label. Parameters list (octets z+1 to v) The parameters list contains a variable number of parameters that may be transferred. If the parameters list is included, the E bit is set to 1; otherwise, the E bit is set to 0. Each parameter included in the parameters list is of variable length and consists of: – a parameter identifier (1 octet); The parameter identifier field is used to identify each parameter included in the parameters list and it contains the hexadecimal coding of the parameter identifier. Bit 8 of the parameter identifier field contains the most significant bit and bit 1 contains the least significant bit. In this version of the protocol, the following parameter identifiers are specified: – 01H (Authorization Token); – 02H (Flow Identifier) ; and If the parameters list contains a parameter identifier that is not supported by the receiving entity the corresponding parameter shall be discarded. The length of parameter contents field contains the binary coded representation of the length of the parameter contents field. The first bit in transmission order is the most significant bit. When the parameter identifier indicates Authorization Token, the parameter contents field contains an authorization token, as specified in 3GPP TS 29.207 [100]. The first octet is the most significant octet of the authorization token and the last octet is the least significant octet of the authorization token. The parameters list shall be coded in a way that an Authorization Token (i.e. a parameter with identifier 01H) is always followed by one or more Flow Identifiers (i.e. one or more parameters with identifier 02H). If the parameters list contains two or more consecutive Authorization Tokens without any Flow Identifiers in between, the receiver shall treat this as a semantical TFT error. When the parameter identifier indicates Flow Identifier, the parameter contents field contains the binary representation of a flow identifier. The Flow Identifier consists of four octets. Octets 1 and 2 contains the Media Component number as specified in 3GPP TS 29.207 [100]. Bit 1 of octet 2 is the least significant bit, and bit 8 of octet 1 is the most significant bit. Octets 3 and 4 contains the IP flow number as specified in 3GPP TS 29.207 [100]. Bit 1 of octet 4 is the least significant bit, and bit 8 of octet 3 is the most significant bit. When the parameter identifier indicates Packet Filter Identifier, the parameter contents field contains the binary representation of one or more packet filter identifiers. Each packet filter identifier is encoded in one octet, in the 4 least significant bits. This parameter is used by the MS to identify one or more packet filters in a TFT when modifying the QoS of a PDP context without modifying the packet filter itself. |
11.9.1.3 Test purpose
1. To verify that the UE, when it has IP packets to transmit, evaluates the configured packet filters in the correct evaluation order and transmits IP packets in uplink on the bearer associated with the matched packet filter when having a primary and two secondary PDP contexts active
- To verify that the UE, when it has IP packets to transmit and only packet filters defined for the secondary PDP contexts, transmits IP packets in uplink on the bearer associated with the primary PDP context, if the IP packet does not satisfy any of the configured packet filters for the secondary PDP contexts.
- To verify that the UE, when it has IP packets to transmit, transmits IP packets in uplink on the bearer associated with the primary PDP context, if the IP packet only satisfies a packet filters defined for the primary PDP context.
- To verify that the UE discards the IP packet if it does not satisfy any of the configured packet filters for the primary or secondary PDP contexts.
11.9.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
– 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 an IPv4 address to the UE and set the test variable IP type to “IPv4”. The SS executes the test sequence once (sub test 1).
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”. The SS executes the test sequence once (sub test 2).
Else if the UE set the PDP type to ‘IPv4IPv6’ in the ACTIVATE PDP CONTEXT REQUEST then the SS executes the test sequence twice. For first execution (sub test 1) then the SS allocates an IPv4 address to the UE and set the test variable IP type to “IPv4”. For the second execution (sub test 2) 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. A third PDP context is activated by the SS using the secondary PDP context activation procedure. Packet Filter#2, Packet Filter#3and Packet Filter#4, depending on the IP type used, are activated.
The SS activates UE test loop mode 4 and transmits 13 or 17 IP packets depending on the IP type used. The SS checks that the IP packets are returned by the UE on the radio bearer corresponding to the matching filter, see Table 11.9.1.4-2.
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#5. The UE sends a MODIFY PDP CONTEXT ACCEPT message in return.
The SS transmits IP packet#18 that matches Packet Filter#5. The SS checks that IP packet#18 is returned by the UE on the radio bearer associated with the primary PDP context. The SS transmits IP packet#19 that does not match any packet filter. The SS checks that no IP packet is returned by the UE on any radio bearer.
The test procedure is executed once for IPv4 case (sub test 1) and once for IPv6 case (sub test 2) dependending on UE capability as specified in Table 11.9.1.4.-1a.
Table 11.9.1.4-1a: Test executions and test parameters
|
Sub test |
Applicability |
IPtype |
|
1 |
UE supporting IPv4 |
‘IPv4’ |
|
2 |
UE supporting IPv6 |
‘IPv6’ |
|
Note 1: For UEs supporting both IPv4 and IPv6 then both test execution 1 and 2 shall be performed. |
||
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′ in the ACTIVATE PDP CONTEXT REQUEST message then the SS sets the test variable IPtype=’IPv4’ and executes the test sequence using the IPv4 packet filters components in Table 11.9.1.4-1. 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’ and executes the test sequence using the IPv6 packet filters components in Table 11.9.1.4-1. ELSE IF the UE in step 5 set the PDP type to ‘ IPv4IPv6′ in the ACTIVATE PDP CONTEXT REQUEST message then the test secuence shall be executed twice according to table 11.9.1.4-1a. At the first execution the SS sets the test variable IPtype=’IPv4′ and executes the test sequence using the IPv4 packet filters components in Table 11.9.1.4-1. At the second execution then the SS sets the test variable IPtype=’IPv6’ and executes the test sequence using the IPv6 packet filters components in Table 11.9.1.4-1. |
||
|
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 If the test variable IPtype is set to ‘IPv4’ then the SS assigns an IPv4 adress in the ACTIVATE PDP CONTEXT ACCEPT message |
|
|
EXCEPTION: If the test variable IPtype is set to ‘IPv6’ then stateless address auto configuration occurs on the user plane bearer established in step 6. |
||||
|
EXCEPTION: If the test variable IPtype is set to ‘IPv6’ then stateless address auto configuration occurs on the user plane bearer established in step 6. |
||||
|
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 5. A UL TFT filter is configured. |
|
|
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 |
|
REQUEST SECONDARY PDP CONTEXT ACTIVATION |
The SS requests a Secondary PDP context activation and starts timer T3385. |
|
|
14 |
|
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 5. UL TFT filters are configured. |
|
|
15 |
SS |
The SS stops timer T3385. The SS reconfigures the RAB according to reference radio bearer combination 6.11.4l.1 in [9] (3xPS RB 64kbps). |
||
|
16 |
|
ACTIVATE SECONDARY PDP CONTEXT ACCEPT |
The SS accepts the Secondary PDP context activation with the requested QoS |
|
|
17 |
SS |
The SS waits for T3380 seconds to ensure no further activate request messages come from the UE |
||
|
18 |
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. |
||
|
EXCEPTION: IF IPtype=’IPv4′ then test steps 19 to 20 are repeated for N= 1 to 13 IF IPtype=’IPv6′ then test steps 19 to 20 are repeated for N= 1 to 17 |
||||
|
19 |
|
IP PDU (IP packet#N) |
The SS transmits one IP Packet according to Table 11.9.1.4-2 for Sub-test index=N |
|
|
20 |
|
IP PDU (IP packet#N) |
Check: Does UE send the IP Packet on the PDP context as specified by Table 11.9.1.4-2 for Sub-test index=N? |
|
|
21 |
|
MODIFY PDP CONTEXT REQUEST (NETWORK TO UE DIRECTION) |
The SS sends a modify request to UE to add a UL TFT filter to the primary PDP context |
|
|
22 |
|
MODIFY PDP CONTEXT ACCEPT (UE TO NETWORK DIRECTION) |
The UE accepts the modification request from the SS. |
|
|
23 |
|
IP PDU (IP packet#18) |
The SS transmits one IP Packet according to Table 11.9.1.4-2 for Sub-test index=18 |
|
|
24 |
|
IP PDU (IP packet#18) |
Check: Does UE send the IP Packet on the data radio bearer as specified by Table 11.9.1.4-2 for Sub-test index=18? |
|
|
25 |
|
IP PDU (IP packet#19) |
The SS transmits one IP Packet according to Table 11.9.1.4-2 for Sub-test index=19 |
|
|
26 |
Check: Does UE send an IP Packet on any of the PDP contexts? |
|||
|
EXCEPTION: Steps 27 – 33 are executed if two executions apply and this is the first execution. |
||||
|
27 |
|
OPEN UE TEST LOOP |
The SS transmits an OPEN UE TEST LOOP message to exit the UE test loop mode |
|
|
28 |
|
OPEN UE TEST LOOP COMPLETE |
The UE transmits an OPEN UE TEST LOOP COMPLETE message. |
|
|
29 |
|
DEACTIVATE RB TEST MODE |
The SS requests the UE to deactivate the UE radio bearer test mode by transmitting a DEACTIVATE RB TEST MODE message |
|
|
30 |
|
DEACTIVATE RB TEST MODE COMPLETE |
The UE deactivates the radio bearer test mode ans transmits the DEACTIVATE RB TEST MODE COMPLETE message |
|
|
31 |
Void |
|||
|
32 |
Void |
|||
|
33 |
The SS releases the RRC connection. |
|||
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 request includes a bi-directional packet filter. For details please refer 23.060 Sec 9.2.2.3.
Step 10: The request includes an UL TFT filter, Packet Filter#1. Packet Filter#1 is set according to table 11.9.1.4-1
Step 14: The request includes UL TFT filters. If PDP type was set to “IPv4” in step 5 then Packet Filter#2 and Packet Filter#3, according to table 11.9.1.4-1, are included. If PDP type was set to “iIPv6 or “IPv4v6” in step 5 then Packet Filter#2, Packet Filter#3and Packet Filter#4, to table 11.9.1.4-1, are included.
Step 18: 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 19: IP packet#N is set according to table 11.9.1.4-2
Step 21: The request includes an UL TFT filter Packet Filter#5 according to table 11.9.1.4-1.
Step 23: IP packet#18 is set according to table 11.9.1.4-5
Step 25: IP packet#19 is set according to table 11.9.1.4-5
Table 11.9.1.4-1: Packet Filter Table
|
Packet filter components |
||||||||||||
|
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 10) |
6 |
17 (UDP) |
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 |
Secondary PDP Context (Step 14) |
7 |
17 (UDP) |
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 range of 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. |
|
3 |
Secondary PDP Context (Step 14) |
5 |
50 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::] |
– |
– |
– |
– |
0x0F80F000 |
10100000, Mask= |
– |
IPSec session. Example from TS 23.060 cl 15.3.3.3 This is a valid Packet Filter Attribute Combination Type II according to TS 23.060, subclause 15.3.2.0. |
|
4 |
Secondary PDP Context (Step 14) |
2 |
– |
IPv6: 2001:0ba0:: [ffff:ffff::] |
– |
– |
– |
– |
– |
10110000, Mask= |
5 |
IPv6 Flow Label filter This is a valid Packet Filter Attribute Combination Type III according to TS 23.060, subclause 15.3.2.0. |
|
5 |
Primary PDP Context (Step 21) |
255 |
IPv4: 172.168.8.0 [255.255.255.0] IPv6: 2001:0ba0:: [ffff:ffff::]- |
– |
– |
– |
– |
– |
– |
– |
Application identified by remote address and specific local port number. This is a valid Packet Filter Attribute Combination Type I according to TS 23.060, subclause 15.3.2.0. |
|
Table 11.9.1.4-2: Sub-test test parameters and test requirements
|
Sub-test Index |
Test data (IP packet) Note 1 |
Expected PDP context for the matching packet filter |
Packet Filter Attribute Combination under test |
Packet Filter Component under test |
Comment |
|
1 |
IP packet#1 |
Secondary PDP Context (Step 10) |
Type I |
All Type I packet filter components match |
The IP packet is only matching Packet Filter 1 and 2 in Table 11.9.1.4-1. The IP packet is returned on Secondary PDP Context (Step 10) as Packet Filter 1 is evaluated before Packet Filter 2. |
|
2 |
IP packet#2 |
Primary PDP Context (Step 5) |
Type I |
Remote Address does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
3 |
IP packet#3 |
Primary PDP Context (Step 5) |
Type I |
Protocol identifier/Next header does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
4 |
IP packet#4 |
Secondary PDP Context (Step 14) |
Type I |
Single local port does not match |
The IP packet is only matching Packet Filter 2 in Table 11.9.1.4-1. The IP packet is returned on Secondary PDP Context (Step 14). |
|
5 |
IP packet#5 |
Primary PDP Context (Step 5) |
Type I |
Local port range does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
6 |
IP packet#6 |
Secondary PDP Context (Step 10) |
Type I |
Single remote port does not match |
IP packet is only matching Packet Filter 1 in Table 11.9.1.4-1. The IP packet is returned on Secondary PDP Context (Step 10). |
|
7 |
IP packet#7 |
Primary PDP Context (Step 5) |
Type I |
Remote port range does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
8 |
IP packet#8 |
Primary PDP Context (Step 5) |
Type I |
Type of service/Traffic class does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
9 |
IP packet#9 |
Secondary PDP Context (Step 14) |
Type II |
All Type II packet filter components match |
The IP packet is only matching Packet Filter 3 in Table 11.9.1.4-1. The IP packet is returned on DRB3. |
|
10 |
IP packet#10 |
Primary PDP Context (Step 5) |
Type II |
Remote Address does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
11 |
IP packet#11 |
Primary PDP Context (Step 5) |
Type II |
Protocol identifier/Next header does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
12 |
IP packet#12 |
Primary PDP Context (Step 5) |
Type II |
Security parameter index does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
13 |
IP packet#13 |
Primary PDP Context (Step 5) |
Type II |
Type of service/Traffic class does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
14 |
IP packet#14 |
Secondary PDP Context (Step 14) |
Type III |
All Type III packet filter components match |
The IP packet is only matching Packet Filter 4 in Table 11.9.1.4-1. The IP packet is returned on Secondary PDP Context (Step 14) |
|
15 |
IP packet#15 |
Primary PDP Context (Step 5) |
Type III |
Remote Address does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
16 |
IP packet#16 |
Primary PDP Context (Step 5) |
Type III |
Type of service/Traffic class does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
17 |
IP packet#17 |
Primary PDP Context (Step 5) |
Type III |
Flow Label does not match |
No packet filter matches. The IP packet is returned on Primary PDP Context |
|
18 |
IP packet#18 |
Primary PDP Context (Step 21) |
Type I |
Remote Address match |
IP packet is only matching Packet Filter 5 in Table 11.9.1.4-1 |
|
19 |
IP packet#19 |
None |
Type I |
Remote Address does not match |
IP packet does not match any Packet Filters |
|
Note 1: IP Packet details are specified in Tables 11.9.1.4-3 to 11.9.1.4-21 Note 2: IP packets for sub-test index 1 to 17 are sent by the SS while no TFT is assigned to the Primary PDP Context. IP packets for sub-test index 18 and 19 are sent by the SS after adding a TFT to the Primary PDP Context. |
|||||
Table 11.9.1.4-3: IP packet#1 (Table 11.9.1.4-2)
|
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, 2, 3, and 4. Value matches packet filters 1 and 2. Value does not match packet filters 3 or 4. |
|
|
Protocol |
17 |
UDP Significant packet filters 1, 2 and 3. Value matches packet filters 1 and 2. Value does not match packet filter 3. |
|
|
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.8.1 |
Significant for packet filters 1, 2 and 3. Value matches packet filters 1, 2 and 3. |
IPv4 |
|
2001:0ba0::0001:0001 |
Significant for packet filters 1, 2, 3 and 4. Value matches packet filters 1, 2, 3 and 4. |
IPv6 |
|
|
Source Port |
60001 |
Significant for packet filters 1 and 2. Value matches packet filters 1 and 2. |
|
|
Destination Port |
60350 |
Significant for packet filters 1 and 2. Value matches packet filters 1 and 2. |
|
|
Flow Label |
10 |
Significant for packet filter 4. Value does not match packet filter 4. |
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.9.1.4-4: IP packet#2 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destination Address |
172.168.9.1 |
Significant for packet filter 1, 2 and 3. Value does not match packet filters 1, 2 or 3. |
IPv4 |
|
2001:0bb0::0001:0001 |
Significant for packet filter 1, 2, 3 and 4. Value does not match packet filters 1, 2, 3 or 4. |
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.9.1.4-5: IP packet#3 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Protocol |
6 |
TCP Significant packet filters 1, 2 and 3. Value does not match packet filters 1, 2 or 3. |
|
Table 11.9.1.4-6: IP packet#4 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Source Port |
60002 |
Significant for packet filters 1 and 2. Value matches packet filter 2. Value does not match packet filter 1. |
|
Table 11.9.1.4-7: IP packet#5 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Source Port |
60101 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
Table 11.9.1.4-8: IP packet#6 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destination Port |
60351 |
Significant for packet filters 1 and 2. Value matches packet filter 1. Value does not match packet filter 2 |
|
Table 11.9.1.4-9: IP packet#7 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destination Port |
60451 |
Significant for packet filters 1 and 2. Value does not match packet filter 1 or 2. |
|
Table 11.9.1.4-10: IP packet#8 (Table 11.9.1.4-2)
|
Derivation path: IP packet#1, Table 11.9.1.4-3 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Type of service (IPv4) / Traffic Class (IPv6) |
11101001 |
Significant for packet filters 1, 2, 3, and 4. Value does not match packet filters 1, 2, 3 or 4. |
|
Table 11.9.1.4-11: IP packet#9 (Table 11.9.1.4-2)
|
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) |
10100010 |
Significant for packet filters 1, 2, 3, and 4. Value matches packet filter 3. Value does not match packet filters 1, 2 or 4. |
|
|
Protocol |
50 |
IPSec (ESP) Significant packet filters 1, 2 and 3. Value matches packet filter 3. Value does not match packet filters 1 or 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.8.1 |
Significant for packet filters 1, 2 and 3. Value matches packet filters 1, 2 and 3. |
IPv4 |
|
2001:0ba0::0001:0001 |
Significant for packet filters 1, 2, 3 and 4. Value matches packet filters 1, 2, 3 and 4. |
IPv6 |
|
|
Source Port |
60101 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
Destination Port |
60451 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
IP Sec SPI range |
0x0F80F0000 |
Significant for packet filter 3. Value matches packet filter 3. |
|
|
Flow Label |
10 |
Significant for packet filter 4. Value does not match packet filter 4. |
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.9.1.4-12: IP packet#10 (Table 11.9.1.4-2)
|
Derivation path: IP packet#9, Table 11.9.1.4-11 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destination Address |
172.168.9.1 |
Significant for packet filter 1, 2 and 3. Value does not match packet filters 1, 2 or 3. |
IPv4 |
|
2001:0bb0::0001:0001 |
Significant for packet filter 1, 2, 3 and 4. Value does not match packet filters 1, 2, 3 or 4. |
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.9.1.4-13: IP packet#11 (Table 11.9.1.4-2)
|
Derivation path: IP packet#9, Table 11.9.1.4-11 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Protocol |
6 |
TCP Significant packet filters 1, 2 and 3. Value does not match packet filters 1, 2 or 3. |
|
Table 11.9.1.4-14: IP packet#12 (Table 11.9.1.4-2)
|
Derivation path: IP packet#9, Table 11.9.1.4-11 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
IP Sec SPI range |
0x0F90F0000 |
Significant for packet filter 3. Value does not match packet filter 3. |
|
Table 11.9.1.4-15: IP packet#13 (Table 11.9.1.4-2)
|
Derivation path: IP packet#9, Table 11.9.1.4-11 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Type of service (IPv4) / Traffic Class (IPv6) |
11101001 |
Significant for packet filters 1, 2, 3 and 4. Value does not match packet filters 1, 2, 3 or 4. |
|
Table 11.9.1.4-16: IP packet#14 (Table 11.9.1.4-2)
|
Derivation path: RFC 2460 section 3 (IPv6) and RFC 769 introduction |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Traffic Class (IPv6) |
10110011 |
Significant for packet filters 1, 2, 3, and 4. Value matches packet filter 4. Value does not match packet filters 1, 2 or 3. |
|
|
Protocol |
6 |
TCP Significant packet filters 1, 2 and 3. Value does not match packet filters 1, 2 or 3. |
|
|
Source Address |
fe80::1:1 |
IPv6 Not significant for any packet filters |
|
|
Destination Address |
2001:0ba0::0001:0001 |
IPv6 Significant for packet filters 1, 2, 3 and 4. Value matches packet filters 1, 2, 3 and 4. |
|
|
Source Port |
60101 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
Destination Port |
60451 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
Flow Label |
5 |
IPv6 Significant for packet filter 4. Value matches packet filter 4. |
|
Table 11.9.1.4-17: IP packet#15 (Table 11.9.1.4-2)
|
Derivation path: IP packet#14, Table 11.9.1.4-16 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destination Address |
2001:0bb0::0001:0001 |
IPv6 Significant for packet filter 1, 2, 3 and 4. Value does not match packet filters 1, 2, 3 or 4. |
|
Table 11.9.1.4-18: IP packet#16 (Table 11.9.1.4-2)
|
Derivation path: IP packet#14, Table 11.9.1.4-16 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Type of service (IPv4) / Traffic Class (IPv6) |
11101001 |
Significant for packet filters 1, 2, 3 and 4. Value does not match packet filters 1, 2, 3 or 4. |
|
Table 11.9.1.4-19: IP packet#17 (Table 11.9.1.4-2)
|
Derivation path: IP packet#14, Table 11.9.1.4-16 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Flow Label |
10 |
IPv6 Significant for packet filter 4. Value does not match packet filter 4. |
|
Table 11.9.1.4-20: IP packet#18 (Table 11.9.1.4-2)
|
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) |
10101010 |
Significant for packet filters 1, 2, 3, and 4. Value matches packet filter 1 and 2. Value does not match packet filters 3 or 4. |
|
|
Protocol |
6 |
TCP Significant packet filters 1, 2 and 3 .Value does not match packet filters 1, 2 or 3. |
|
|
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.8.1 |
Significant for packet filters 1, 2, 3 and 5. Value matches packet filters 1, 2, 3 and 5. |
IPv4 |
|
2001:0ba0::0001:0001 |
Significant for packet filters 1, 2, 3, 4 and 5. Value matches packet filters 1, 2, 3, 4 and 5. |
IPv6 |
|
|
Source Port |
60101 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
Destination Port |
60451 |
Significant for packet filters 1 and 2. Value does not match packet filters 1 or 2. |
|
|
Flow Label |
10 |
Significant for packet filter 4. Value does not match packet filter 4. |
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.9.1.4-21: IP packet#19 (Table 11.9.1.4-2)
|
Derivation path: IP packet#18, Table 11.9.1.4-20 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
Destinaton Address |
172.168.9.1 |
Significant for packet filters 1, 2, 3 and 5. Value does not match packet filters 1, 2, 3 and 5. |
IPv4 |
|
2001:0ba1::0001:0001 |
Significant for packet filters 1, 2, 3, 4 and 5. Value does not match packet filters 1, 2, 3, 4 and 5. |
IPv6 |
|
11.9.1.5 Test requirements
To pass the test the UE shall:
– at step 20 transmit an IP PDU containing IP Packet#N on the radio bearer associated with the PDP context as specified by Table 11.9.1.4-2 for Sub-test index=N.
– at step 22 send a MODIFY PDP CONTEXT ACCEPT message.
– at step 24 transmit an IP PDU containing IP Packet#18 on the radio bearer associated with the PDP context as specified by Table 11.9.1.4-2 for Sub-test index=18.
– at step 26 not transmit any IP PDU