10.1.2 Network-requested PDU session modification
38.523-13GPP5GSPart 1: ProtocolRelease 17TSUser Equipment (UE) conformance specification
10.1.2.1 Network-requested PDU session modification / Accepted
10.1.2.1.1 Test Purpose (TP)
(1)
with { the UE in 5GMM-REGISTERED state with an established PDU session }
ensure that {
when { the UE receives a PDU SESSION MODIFICATION COMMAND message }
then { UE sends a PDU SESSION MODIFICATION COMPLETE message and modifies the PDU session accordingly }
}
(2)
with { the UE in 5GMM-REGISTERED state with an established PDU session has been modified }
ensure that {
when { the UE has IP packets for transmission where each IP packet matches the modified packet filters configured in the UL TFTs for the PDU session }
then { the UE evaluates the packet filters in the correct evaluation order and transmits IP packets in uplink on the dedicated PDU session associated with the matched packet filter }
}
10.1.2.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.501, clauses 6.3.2.3 and TS 24.008, clause 10.5.6.12. Unless otherwise stated these are Rel-15 requirements.
[TS 24.501, clause 6.3.2.3]
Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided a DNN during the PDU session establishment, the UE shall stop timer T3396, if it is running for the DNN provided by the UE. If the UE did not provide a DNN during the PDU session establishment and the request type was different from "initial emergency request" and different from "existing emergency PDU session", the UE shall stop the timer T3396 associated with no DNN if it is running. If the PDU SESSION MODIFICATION COMMAND message was received for an emergency PDU session, the UE shall not stop the timer T3396 associated with no DNN if it is running.
Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided an S-NSSAI and a DNN during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [S-NSSAI, DNN] combination provided by the UE. If the UE did not provide an S-NSSAI during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [no S-NSSAI, DNN] combination provided by the UE. If the UE provided neither a DNN nor an S-NSSAI during the PDU session establishment, the UE shall stop timer T3584, if it is running for the same [no S-NSSAI, no DNN] combination provided by the UE.
Upon receipt of the PDU SESSION MODIFICATION COMMAND message, if the UE provided an S-NSSAI during the PDU session establishment, the UE shall stop timer T3585, if it is running for the S-NSSAI provided by the UE. If the UE did not provide an S-NSSAI during the PDU session establishment and the request type was different from "initial emergency request" and different from "existing emergency PDU session", the UE shall stop the timer T3585 associated with no S-NSSAI if it is running. If the PDU SESSION MODIFICATION COMMAND message was received for an emergency PDU session, the UE shall not stop the timer T3585 associated with no S-NSSAI if it is running.
NOTE 1: Upon receipt of the PDU SESSION MODIFICATION COMMAND message for a PDU session, if the UE provided a DNN (or no DNN) and an S-NSSAI (or no S-NSSAI) when the PDU session is established, timer T3396 associated with the DNN (or no DNN, if no DNN was provided by the UE) is running, and timer T3584 associated with the DNN (or no DNN, if no DNN was provided by the UE) and the S-NSSAI (or no S-NSSAI, if no S-NSSAI was provided by the UE) is running, then the UE stops both the timer T3396 and the timer T3584.
NOTE 2: Upon receipt of the PDU SESSION MODIFICATION COMMAND message for a PDU session, if the UE provided a DNN (or no DNN) and an S-NSSAI (or no S-NSSAI) when the PDU session is established, timer T3585 associated with the S-NSSAI (or no S-NSSAI, if no S-NSSAI was provided by the UE) is running, and timer T3584 associated with the DNN (or no DNN, if no DNN was provided by the UE) and the S-NSSAI (or no S-NSSAI, if no S-NSSAI was provided by the UE) is running, then the UE stops both the timer T3585 and the timer T3584.
If the PDU SESSION MODIFICATION COMMAND message includes the Authorized QoS rules IE, the UE shall process the QoS rules sequentially starting with the first QoS rule.
The UE shall replace the stored authorized QoS rules, authorized QoS flow descriptions and session-AMBR of the PDU session with the received value(s), if any, in the PDU SESSION MODIFICATION COMMAND message.
If the PDU SESSION MODIFICATION COMMAND message includes a Mapped EPS bearer contexts IE, the UE shall check each mapped EPS bearer context for different types of errors as follows:
NOTE 3: An error detected in a mapped EPS bearer context does not cause the UE to discard the Authorized QoS rules IE and Authorized QoS flow descriptions IE included in the PDU SESSION MODICATION COMMAND message, if any.
a) Semantic error in the mapped EPS bearer operation:
1) operation code = "Create new EPS bearer" and there is already an existing mapped EPS bearer context with the same EPS bearer identity associated with any PDU session.
2) operation code = "Delete existing EPS bearer" and there is no existing mapped EPS bearer context with the same EPS bearer identity associated with the PDU session that is being modified.
3) operation code = "Modify existing EPS bearer" and there is no existing mapped EPS bearer context with the same EPS bearer identity associated with the PDU session that is being modified.
In case 1, if the existing mapped EPS bearer context is associated with the PDU session that is being modified, the UE shall not diagnose an error, further process the create request and, if it was process successfully, delete the old EPS bearer context.
In case 2, the UE shall not diagnose an error, further process the delete request and, if it was processed successfully, consider the mapped EPS bearer context as successfully deleted.
Otherwise, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #85 "Invalid mapped EPS bearer identity".
b) if the mapped EPS bearer context includes a traffic flow template, the UE shall check the traffic flow template for different types of TFT IE errors as follows:
2) Semantic errors in TFT operations:
i) TFT operation = "Create a new TFT" when there is already an existing TFT for the EPS bearer context.
ii) When the TFT operation is an operation other than "Create a new TFT" and there is no TFT for the EPS bearer context.
iii) TFT operation = "Delete packet filters from existing TFT" when it would render the TFT empty.
iv) TFT operation = "Delete existing TFT" for a dedicated EPS bearer context.
In case iv, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #41 "semantic error in the TFT operation".
In the other cases the UE shall not diagnose an error and perform the following actions to resolve the inconsistency:
In case i, the UE shall further process the new activation request and, if it was processed successfully, delete the old TFT.
In case ii, the UE shall:
– process the new request and if the TFT operation is "Delete existing TFT" or "Delete packet filters from existing TFT", and if no error according to items b, c, and d was detected, consider the TFT as successfully deleted;
– process the new request as an activation request, if the TFT operation is "Add packet filters in existing TFT" or "Replace packet filters in existing TFT".
In case iii, if the packet filters belong to a dedicated EPS bearer context, the UE shall process the new deletion request and, if no error according to items b, c, and d was detected, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #41 "semantic error in the TFT operation".
In case iii, if the packet filters belong to the default EPS bearer context, the UE shall process the new deletion request and if no error according to items b, c, and d was detected then delete the existing TFT, this corresponds to using match-all packet filter for the default EPS bearer context.
2) Syntactical errors in TFT operations:
i) When the TFT operation = "Create a new TFT", "Add packet filters in existing TFT", "Replace packet filters in existing TFT" or "Delete packet filters from existing TFT" and the packet filter list in the TFT IE is empty.
ii) TFT operation = "Delete existing TFT" or "No TFT operation" with a non-empty packet filter list in the TFT IE.
iii) TFT operation = "Replace packet filters in existing TFT" when the packet filter to be replaced does not exist in the original TFT.
iv) TFT operation = "Delete packet filters from existing TFT" when the packet filter to be deleted does not exist in the original TFT.
v) TFT operation = "Delete packet filters from existing TFT" with a packet filter list also including packet filters in addition to the packet filter identifiers.
vi) When there are other types of syntactical errors in the coding of the TFT IE, such as a mismatch between the number of packet filters subfield, and the number of packet filters in the packet filter list.
In case iii, the UE shall not diagnose an error, further process the replace request and, if no error according to items c and d was detected, include the packet filters received to the existing TFT.
In case iv, the UE shall not diagnose an error, further process the deletion request and, if no error according to items c and d was detected, consider the respective packet filter as successfully deleted.
Otherwise, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #42 "syntactical error in the TFT operation".
3) Semantic errors in packet filters:
i) When a packet filter consists of conflicting packet filter components which would render the packet filter ineffective, i.e. no IP packet will ever fit this packet filter. How the UE determines a semantic error in a packet filter is outside the scope of the present document.
ii) When the resulting TFT, which is assigned to a dedicated EPS bearer context, does not contain any packet filter applicable for the uplink direction among the packet filters created on request from the network.
After sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #44 "semantic errors in packet filter(s)".
4) Syntactical errors in packet filters:
i) When the TFT operation = "Create a new TFT", "Add packet filters to existing TFT", and two or more packet filters in the resultant TFT would have identical packet filter identifiers.
ii) When the TFT operation = "Create a new TFT", "Add packet filters to existing TFT" or "Replace packet filters in existing TFT", and two or more packet filters among all TFTs associated with this PDN connection would have identical packet filter precedence values.
iii) When there are other types of syntactical errors in the coding of packet filters, such as the use of a reserved value for a packet filter component identifier.
In case i, if two or more packet filters with identical packet filter identifiers are contained in the new request, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical error in packet filter(s)". Otherwise, the UE shall not diagnose an error, further process the new request and, if it was processed successfully, delete the old packet filters which have the identical packet filter identifiers.
In case ii, if the old packet filters do not belong to the default EPS bearer context, the UE shall not diagnose an error, shall further process the new request and, if it was processed successfully, shall delete the old packet filters which have identical filter precedence values.
In case ii, if one or more old packet filters belong to the default EPS bearer context, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical errors in packet filter(s)".
Otherwise, after sending the PDU SESSSION MODIFICATION COMPLETE for the ongoing PDU session modification procedure, the UE shall initiate a PDU session modification procedure by sending a PDU SESSION MODIFICATION REQUEST message to delete the mapped EPS bearer context with 5GSM cause #45 "syntactical error in packet filter(s)".
And if a new EPS bearer identity parameter in authorized QoS flow descriptions IE is received for a QoS flow which can be transferred to EPS, the UE shall update the association between the QoS flow and the mapped EPS bearer context, based on the new EPS bearer identity and the mapped EPS bearer contexts. If the "Delete existing EPS bearer" operation code in the Mapped EPS bearer contexts IE was received, the UE shall discard the association between the QoS flow and the corresponding mapped EPS bearer context.
Upon receipt of a PDU SESSION MODIFICATION COMMAND message and a PDU session ID, using the NAS transport procedure as specified in subclause 5.4.5, if the UE accepts the PDU SESSION MODIFICATION COMMAND message, the UE considers the PDU session as modified and the UE shall create a PDU SESSION MODIFICATION COMPLETE message.
If the PDU SESSION MODIFICATION COMMAND message contains the PTI value allocated in the UE-requested PDU session modification procedure, the UE shall stop the timer T3581. The UE should ensure that the PTI value assigned to this procedure is not released immediately.
NOTE 4: The way to achieve this is implementation dependent. For example, the UE can ensure that the PTI value assigned to this procedure is not released during the time equal to or greater than the default value of timer T3591.
While the PTI value is not released, the UE regards any received PDU SESSION MODIFICATION COMMAND message with the same PTI value as a network retransmission (see subclause 7.3.1).
If the selected SSC mode of the PDU session is "SSC mode 3" and the PDU SESSION MODIFICATION COMMAND message includes 5GSM cause #39 "reactivation requested", the UE can provide to the upper layers the PDU session address lifetime if received in the PDU session address lifetime PCO parameter of the Extended protocol configuration options IE of the PDU SESSION MODIFICATION COMMAND message. After the completion of the network-requested PDU session modification procedure, the UE should re-initiate the UE-requested PDU session establishment procedure with a new PDU session ID as specified in subclause 6.4.1 for:
a) the PDU session type associated with the present PDU session;
b) the SSC mode associated with the present PDU session;
c) the DNN associated with the present PDU session; and
d) the S-NSSAI associated with (if available in roaming scenarios) a mapped S-NSSAI if provided in the UE-requested PDU session establishment procedure of the present PDU session.
The UE shall include the PDU session ID of the old PDU session which is about to get released in the old PDU session ID IE of the UL NAS TRANSPORT message that transports the PDU SESSION ESTABLISHMENT REQUEST message.
NOTE 5: The UE is expected to maintain the PDU session for which the PDU SESSION MODIFICATION COMMAND message including 5GSM cause #39 "reactivation requested" is received during the time indicated by the PDU session address lifetime value or until receiving an indication from upper layers (e.g. that the old PDU session is no more needed).
If the selected PDU session type of the PDU session is "Unstructured" or "Ethernet", the UE supports inter-system change from N1 mode to S1 mode, the UE does not support establishment of a PDN connection for the PDN type set to "non-IP" in S1 mode, and the parameters list field of one or more authorized QoS flow descriptions received in the authorized QoS flow descriptions IE of the PDU SESSION MODIFICATION COMMAND message contains an EPS bearer identity (EBI) then the UE shall locally remove the EPS bearer identity (EBI) from the parameters list field of such one or more authorized QoS flow descriptions.
If the Always-on PDU session indication IE is included in the PDU SESSION MODIFICATION COMMAND message and:
a) the value of the IE is set to "Always-on PDU session required", the UE shall consider the established PDU session as an always-on PDU session; or
b) the value of the IE is set to "Always-on PDU session not allowed", the UE shall not consider the established PDU session as an always-on PDU session.
If the UE does not receive the Always-on PDU session indication IE in the PDU SESSION MODIFICATION COMMAND message:
a) if the network-requested PDU session modification procedure is triggered by a UE-requested PDU session modification procedure upon the first inter-system change from S1 mode to N1 mode for a PDN connection established when in S1 mode, the UE shall not consider the modified PDU session as an always-on PDU session; or
b) otherwise:
1) if the UE has received the Always-on PDU session indication IE with the value set to "Always-on PDU session required" for this PDU session, the UE shall consider the PDU session as an always-on PDU session; or
2) otherwise the UE shall not consider the PDU session as an always-on PDU session.
The UE shall transport the PDU SESSION MODIFICATION COMPLETE message and the PDU session ID, using the NAS transport procedure as specified in subclause 5.4.5.
After sending the PDU SESSION MODIFICATION COMPLETE message, if the "Create new EPS bearer" operation code in the mapped EPS bearer contexts IE was received in the PDU SESSION MODIFICATION COMMAND message and there is neither a corresponding authorized QoS flow descriptions IE in the PDU SESSION MODIFICATION COMMAND message nor an existing QoS flow description corresponding to the EPS bearer identity included in the mapped EPS bearer context, the UE shall send a PDU SESSION MODIFICATION REQUEST message including a mapped EPS bearer contexts IE to delete the mapped EPS bearer context.
Upon receipt of a PDU SESSION MODIFICATION COMPLETE message, the SMF shall stop timer T3591 and shall consider the PDU session as modified. If the selected SSC mode of the PDU session is "SSC mode 3" and the PDU SESSION MODIFICATION COMMAND message included 5GSM cause #39 "reactivation requested", the SMF shall start timer T3593. If the PDU Session Address Lifetime value is sent to the UE in the PDU SESSION MODIFICATION COMMAND message then timer T3593 shall be started with the same value, otherwise it shall use a default value.
[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 are applicable to both directions. The packet filters determine the traffic mapping to PDP contexts. The downlink packet filters shall be used by the network and the uplink packet filters shall be used by the MS. A packet filter that is applicable to both directions shall be used by the network as a downlink packet filter and by the MS as an uplink packet 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 IE, 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 IE. However, using "Add packet filters to existing TFT", it’s possible to create a TFT data structure 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.
NOTE 3: The 3GPP TS 24.301 [120] reuses the traffic flow template information element for the purpose of the traffic flow aggregate description, where the use of individual TFT parameters, e.g. the packet filter identifier in the parameter list, can differ from this specification.
|
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 |
||
|
0 |
0 |
0 |
0 |
Packet filter identifier 1 |
Octet 4 |
||||
|
Spare |
|||||||||
|
0 |
0 |
0 |
0 |
Packet filter identifier 2 |
Octet 5 |
||||
|
Spare |
|||||||||
|
… |
|||||||||
|
0 |
0 |
0 |
0 |
Packet filter identifier N |
Octet N+3 |
||||
|
Spare |
|||||||||
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 |
||
|
0 |
0 |
Packet filter direction 1 |
Packet filter identifier 1 |
Octet 4 |
|||||
|
Spare |
|||||||||
|
Packet filter evaluation precedence 1 |
Octet 5 |
||||||||
|
Length of Packet filter contents 1 |
Octet 6 |
||||||||
|
Packet filter contents 1 |
Octet 7 Octet m |
||||||||
|
0 |
0 |
Packet filter direction 2 |
Packet filter identifier 2 |
Octet m+1 |
|||||
|
Spare |
|||||||||
|
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 |
||||||||
|
0 |
0 |
Packet filter direction N |
Packet filter identifier N |
Octet y+1 |
|||||
|
Spare |
|||||||||
|
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 Ignore this IE 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 0 No TFT operation 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. The TFT operation code "Ignore this IE" shall be used by the MS if the Traffic flow aggregate information element has presence requirement "M" in a message, but the information element does not serve any useful purpose in the specific procedure for which the message is sent (see 3GPP TS 24.301 [120], subclauses 6.5.3.2 and 6.5.4.2). If the TFT operation code indicates "Ignore this IE", the MS shall also set the E bit and the number of packet filters to zero. If the TFT operation code is set to "Ignore this IE" and the E bit and the number of packet filters to zero, then the network shall ignore the contents of 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 15. 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. The description and valid combinations of packet filter component type identifiers in a packet filter are defined in 3GPP TS 23.060 [74] subclause 15.3.2. 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 "IPv4 local address type", the packet filter component value field shall be encoded as defined for "IPv4 remote address type". 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 "IPv6 remote address/prefix length type", the packet filter component value field shall be encoded as a sequence of a sixteen octet IPv6 address field and one octet prefix length field. The IPv6 address field shall be transmitted first. For "IPv6 local address/prefix length type", the packet filter component value field shall be encoded as defined for "IPv6 remote address /prefix length". Both the MS and network indication for support of the Local address in TFTs are required to use this packet filter component. NOTE: Local IP address and mask can be used when IPv6 prefix delegation is used (see 3GPP TS 23.060 [74] subclause 9.2.1.2). 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) For "destination MAC address type" and "source MAC address type", the packet filter component value field shall be encoded as 6 octets which specify a MAC address. For "802.1Q C-TAG VID type", the packet filter component value field shall be encoded as two octets which specify the VID of the customer-VLAN tag (C-TAG). The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. For "802.1Q S-TAG VID type", the packet filter component value field shall be encoded as two octets which specify the VID of the service-VLAN tag (S-TAG). The bits 8 through 5 of the first octet shall be spare whereas the remaining 12 bits shall contain the VID. For "802.1Q C-TAG PCP/DEI type", the packet filter component value field shall be encoded as one octet which specifies the 802.1Q C-TAG PCP and DEI. The bits 8 through 5 of the octet shall be spare, the bits 4 through 2 contain the PCP and bit 1 contains the DEI. For "802.1Q S-TAG PCP/DEI type", the packet filter component value field shall be encoded as one octet which specifies the 802.1Q S-TAG PCP. The bits 8 through 5 of the octet shall be spare, the bits 4 through 2 contain the PCP and bit 1 contains the DEI. For "ethertype type", the packet filter component value field shall be encoded as two octets which specify an ethertype. 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 and the network to identify one or more packet filters in a TFT when modifying the QoS of a PDP context without modifying the packet filter itself. |
10.1.2.1.3 Test description
10.1.2.1.3.1 Pre-test conditions
System Simulator:
– NGC Cell A.
UE:
– None.
Preamble:
– The UE is in state 3N-A on NGC Cell A with at least one PDU session for Internet active according to TS 38.508-1 [4], clause 4.4A.3 Table 4.4A.3-1 and using the message condition UE TEST LOOP MODE B active.
10.1.2.1.3.2 Test procedure sequence
Table 10.1.2.1.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
1 |
The SS transmits a PDU session modification command message with PDU session ID IE is set to the same value as the first PDU session ID for Internet in the PDU SESSION ESTABLISHMENT REQUEST message. This message is included in a DLInformationTransfer message. |
<– |
PDU SESSION MODIFICATION COMMAND |
– |
– |
|
2 |
Check: Does the UE transmit a PDU session modification complete? |
–> |
PDU SESSION MODIFICATION COMPLETE |
1 |
P |
|
3 |
The SS transmits one IP Packet matching with new packet filter (reference packet filter list #2). |
– |
– |
– |
– |
|
4 |
Check: Does UE send the IP Packet on the data radio bearer associated with the PDU QoS rule? |
– |
– |
2 |
P |
10.1.2.1.3.3 Specific message contents
Table 10.1.2.1.3.3-1: PDU SESSION MODIFICATION COMMAND (Step 1, Table 10.1.2.1.3.2-1)
|
Derivation path: TS 38.508-1 [4], table 4.7.2-9 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
PDU session ID |
The value the first PDU session ID for Internetindicated in PDU SESSION ESTABLISHMENT REQUEST message in the preamble |
||
|
Authorized QoS rules |
Reference QoS rule #3 as defined in 38.508-1 [4] table 4.8.2.1-3. |
||
10.1.2.2 Network-requested PDU session modification / Abnormal / PDU session in state PDU SESSION INACTIVE
10.1.2.2.1 Test Purpose (TP)
(1)
with { the UE in PDU SESSION ACTIVE state and 5GMM-CONNECTED mode }
ensure that {
when { the UE receives a PDU SESSION MODIFICATION COMMAND message include the PDU session ID which belong to any PDU session in PDU SESSION INACTIVE state in UE }
then { UE sends a 5GSM STATUS message and set the 5GSM cause to #43: invalid PDU session identity }
}
10.1.2.2.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.501, clauses 6.3.2.6 and 7.3.2. Unless otherwise stated these are Rel-15 requirements.
[TS 24.501, clause 6.3.2.6]
The following abnormal cases can be identified:
a) PDU session inactive for the received PDU session ID.
If the PDU session ID in the PDU SESSION MODIFICATION COMMAND message belongs to any PDU session in state PDU SESSION INACTIVE in the UE, the UE shall set the 5GSM cause IE to #43 "Invalid PDU session identity" in the 5GSM STATUS message, and set the PDU session ID to the received PDU session ID in the UL NAS TRANSPORT message as specified in subclause 5.4.5.
[TS 24.501, clause 7.3.2]
The following UE procedures shall apply for handling an unknown, erroneous, or unforeseen PDU session identity received in the header of a 5GSM message:
a) If the UE receives a 5GSM message which includes an unassigned or reserved PDU session identity value, the UE shall ignore the message.
b) If the UE receives a 5GSM message which includes a PDU session identity belonging to any PDU session in state PDU SESSION INACTIVE in the UE, the UE shall respond with a 5GSM STATUS message including 5GSM cause #43 "invalid PDU session identity".
10.1.2.2.3 Test description
10.1.2.2.3.1 Pre-test conditions
System Simulator:
– NGC Cell A.
UE:
– None.
Preamble:
– The UE is in state 3N-A on NGC Cell A with at least one PDU session for Internet active according to 38.508-1 [4]
10.1.2.2.3.2 Test procedure sequence
Table 10.1.2.2.3.2-1: Main behaviour
|
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
|
U – S |
Message |
||||
|
0A |
Cause the UE to request establishment of PDU session Y to the DN. (Note 1) |
– |
– |
– |
– |
|
0B |
The PDU session establishment procedure as specified in TS 38.508-1 [4] subclause 4.5A.2 takes place |
– |
– |
– |
– |
|
1 |
The generic test procedure in TS 38.508-1 clause 4.9.21 for PDU Session Release is performed message with PDU session ID IE is set to the same value as the first PDU session ID for Internet in PDU SESSION ESTABLISHMENT REQUEST message in preamble. |
– |
– |
– |
– |
|
2 |
Void |
– |
– |
– |
|
|
3 |
The SS transmits a PDU session modification command message with PDU session ID IE is set to the same value in PDU SESSION RELEASE COMMAND message. This message is included in a DLInformationTransfer message. |
<– |
PDU SESSION MODIFICATION COMMAND |
– |
– |
|
4 |
Check: Does the UE transmit a 5GSM STATUS with the 5GSM cause IE indicating #43 "invalid PDU session identity"? |
–> |
5GSM STATUS |
1 |
P |
|
Note 1: he request of connectivity to an additional PDU session may be performed by MMI or AT command. |
|||||
10.1.2.2.3.3 Specific message contents
Table 10.1.2.2.3.3-1: PDU SESSION MODIFICATION COMMAND (Step 3, Table 10.1.2.2.3.2-1)
|
Derivation path: TS 38.508-1 [4], table 4.7.2-9 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
PDU session ID |
The same value in PDU SESSION RELEASE COMMAND message |
||
Table 10.1.2.2.3.3-2: 5GSM STATUS (Step 4, Table 10.1.2.2.3.2-1)
|
Derivation path: TS 38.508-1 [4], table 4.7.2-16 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
PDU session ID |
The same value as the value set in PDU SESSION modification command message |
||
|
5GSM cause |
‘00101011’B |
Invalid PDU session identity |
|
Table 10.1.2.2.3.3-3: PDU SESSION RELEASE COMMAND (Step 1, Table 10.1.2.2.3.2-1; step 1, TS 36.508 [4] Table 4.9.21.2.2-1)
|
Derivation path: TS 38.508-1 [4], table 4.7.2-14 |
|||
|
Information Element |
Value/Remark |
Comment |
Condition |
|
PDU session ID |
The value of the first PDU session ID for Internet indicatedin PDU SESSION ESTABLISHMENT REQUEST message in preamble |
||