10.3 EPS bearer context modification
36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification
10.3.1 EPS bearer context modification / Success
10.3.1.1 Test Purpose (TP)
(1)
with { the UE is in BEARER CONTEXT ACTIVE STATE and in EMM-CONNECTED mode }
ensure that {
when { the UE receives a MODIFY EPS BEARER CONTEXT REQUEST message with new TFT}
then { the UE sets the new TFT and then transmits a MODIFY EPS BEARER CONTEXT ACCEPT }
}
10.3.1.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 66.4.3.1, 6.4.3.2 and 6.4.3.3.
[TS 24.301, clause 6.4.3.1]
The purpose of the EPS bearer context modification procedure is to modify an EPS bearer context with a specific QoS and TFT. The EPS bearer context modification procedure is initiated by the network, but it may also be initiated as part of the UE requested bearer resource allocation procedure or the UE requested bearer resource modification procedure.
…
[TS 24.301, clause 6.4.3.2]
The MME shall initiate the EPS bearer context modification procedure by sending a MODIFY EPS BEARER CONTEXT REQUEST message to the UE, starting the timer T3486, and entering the state BEARER CONTEXT MODIFY PENDING (see example in figure 6.4.3.2.1).
The MME shall include an EPS bearer identity that identifies the EPS bearer context to be modified in the MODIFY EPS BEARER CONTEXT REQUEST message.
[TS 24.301, clause 6.4.3.3]
Upon receipt of the MODIFY EPS BEARER CONTEXT REQUEST message, the UE shall first check the received TFT before taking it into use and then send a MODIFY EPS BEARER CONTEXT ACCEPT message to the MME.
If the PTI is included in the MODIFY EPS BEARER CONTEXT REQUEST message, the UE uses the PTI to identify the UE requested bearer resource allocation procedure or the UE requested bearer resource modification procedure to which the EPS bearer context modification is related (see subclause 6.5.3 and subclause 6.5.4).
If the PTI is included in the MODIFY EPS BEARER CONTEXT REQUEST message and the PTI is associated to a UE requested bearer resource allocation procedure or a UE requested bearer resource modification procedure, the UE shall release the traffic flow aggregate description associated to the PTI value provided.
The UE shall use the received TFT to apply mapping of uplink traffic flows to the radio bearer if the TFT contains packet filters for the uplink direction.
Upon receipt of the MODIFY EPS BEARER CONTEXT ACCEPT message, the MME shall stop the timer T3486 and enter the state BEARER CONTEXT ACTIVE.
10.3.1.3 Test description
10.3.1.3.1 Pre-test conditions
System Simulator:
– Cell A is configured according to Table 6.3.2.2-1 in [18].
UE:
None.
Preamble:
– The UE is in state Switched OFF (State 1).
10.3.1.3.2 Test procedure sequence
The test procedure in Table 10.3.1.3.2-1 is executed once for IPv4 case (sub test 1) and once for IPv6 case (sub test 2) dependent on UE capability as specified in Table 10.3.1.3.2-2a.
Table 10.3.1.3.2-1a: Test executions and test parameters
Sub test |
Applicability |
IP type |
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. |
Table 10.3.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
The SS performs the generic procedure to get UE in Loopback Activated (state 4) with a Reference default EPS bearer context #1 and Reference dedicated EPS bearer context #1 according to [18] on Cell A. |
||||
1 |
The SS transmits a MODIFY EPS BEARER CONTEXT REQUEST message with new TFT. This message is included in a DLInformationTransfer message. |
<– |
MODIFY EPS BEARER CONTEXT REQUEST |
– |
– |
2 |
Check: Does the UE transmit a MODIFY EPS BEARER CONTEXT ACCEPT message? |
–> |
MODIFY EPS BEARER CONTEXT ACCEPT |
1 |
P |
3 |
Void |
– |
– |
– |
– |
4 |
The SS transmits one IP Packet matching with new TFT (reference packet filter #3) but not existing uplink packet filters (reference packet filter #2). |
– |
– |
– |
– |
5 |
Check: Does UE send the IP Packet on the data radio bearer associated with the dedicated EPS bearer context? |
– |
– |
1 |
P |
– |
EXCEPTION: Steps 6 – 15 are executed only if two executions apply and this is the first execution |
– |
– |
– |
– |
6 |
The SS transmits an OPEN UE TEST LOOP message to exit the UE test loop mode. |
<– |
RRC: DLInformationTransfer TC: OPEN UE TEST LOOP |
– |
– |
7 |
The UE transmits an OPEN UE TEST LOOP COMPLETE message. |
–> |
RRC: ULInformationTransfer TC: OPEN UE TEST LOOP COMPLETE |
– |
– |
8 |
The SS transmits an DEACTIVATE TEST MODE message to de-activate UE radio bearer test mode procedure. |
<– |
RRC: DLInformationTransfer TC: DEACTIVATE TEST MODE |
– |
– |
9 |
The UE transmits a DEACTIVATE TEST MODE COMPLETE message. |
–> |
RRC: ULInformationTransfer TC: DEACTIVATE TEST MODE COMPLETE |
– |
– |
10 |
Void |
– |
– |
– |
– |
11 |
Void |
– |
– |
– |
– |
12 |
Void |
– |
– |
– |
– |
13 |
Void |
– |
– |
– |
– |
14 |
The UE is switched OFF. See Note. |
– |
– |
– |
– |
15 |
The UE is switched ON. |
– |
– |
– |
– |
Note: This implies detaching of the UE, releasing of the RRC connection and resetting of the radio bearers at the SS side. |
10.3.1.3.3 Specific message contents
Table 10.3.1.3.3-0: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (Test execution 2: step 0, Table 10.3.1.3.2-1)
Derivation Path: 36.508 table 4.7.3-6 |
||||||||
Information Element |
Value/remark |
Comment |
Condition |
|||||
PDN address |
||||||||
Length of PDN address contents |
9 octets |
|||||||
PDN type value |
‘010’B |
IPv6 |
||||||
PDN address information |
IPv6 interface identifier |
The SS provides a valid IPv6 interface identifier |
||||||
ESM cause |
IF "PDN type" IE in step 4 (preamble) is ‘IPv4v6’ THEN ‘00110011’B ELSE Not present |
"PDN type IPv6 only allowed" |
||||||
NOTE: IF MULTI_PDN according to the definition in TS 36.508 clause 4.5.2 [18] THEN the above IE values apply for the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST messages sent from the SS in step 16 and step 18c2 of the UE registration with test mode activation procedure acc. to TS 36.508 clause 4.5.2A.3-1 [18]. |
Table 10.3.1.3.3-0A: ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (Test execution 1: step 0, Table 10.3.1.3.2-1)
Derivation Path: 36.508 table 4.7.3-6 |
||||||||
Information Element |
Value/remark |
Comment |
Condition |
|||||
PDN address |
||||||||
Length of PDN address contents |
5 octets |
|||||||
PDN type value |
‘001’B |
IPv4 |
||||||
PDN address information |
IPv4 address |
The SS provides a valid IPv4 address |
||||||
ESM cause |
IF "PDN type" IE in step 4 (preamble) is ‘IPv4v6’ THEN ‘00110010’B ELSE Not present |
"PDN type IPv4 only allowed" |
||||||
NOTE: IF MULTI_PDN according to the definition in TS 36.508 clause 4.5.2 [18] THEN the above IE values apply for the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST messages sent from the SS in step 16 and step 18c2 of the UE registration with test mode activation procedure acc. to TS 36.508 clause 4.5.2A.3-1 [18]. |
Table 10.3.1.3.3-1: Message MODIFY EPS BEARER CONTEXT REQUEST (step 1, Table 10.3.1.3.2-1)
Derivation path: 36.508 table 4.7.3-16 and table 4.6.1-3 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EPS bearer identity |
6 |
SS assigns the current dedicated EPS bearer context. |
|
Procedure transaction identity |
0 |
"No procedure transaction identity assigned" |
|
TFT |
According to reference dedicated EPS bearer context #2 except for TFT operation code – see [18] |
SS modifies the current packet filters of the dedicated EPS bearer context. |
|
TFT operation code |
Replace packet filters in existing TFT |
Table 10.3.1.3.3-2: Message MODIFY EPS BEARER CONTEXT ACCEPT (step 2, Table 10.3.1.3.2-1)
Derivation path: 36.508 table 4.7.3-14 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
EPS bearer identity |
6 |
Same value as in MODIFY EPS BEARER CONTEXT REQUEST |
|
Procedure transaction identity |
0 |
"No procedure transaction identity assigned" |
Table 10.3.1.3.3-2A: Void
Table 10.3.1.3.3-2 B: IP packet (step 4, Table 10.3.1.3.2-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 |
Protocol |
17 |
UDP Same value as reference packet filter #2. Reference packet filter #3 can match all values of ‘Protocol’ |
|
Source Address |
remoteIPv4 |
Same value as in reference packet filters#2 and #3 |
|
remoteIPv6 |
Same value as in reference packet filters#2 and #3 |
IPv6-only |
|
Destination Address |
remoteIPv4 |
Same value as in reference packet filters#2 and #3 |
|
remoteIPv6 |
Same value as in reference packet filters #2 and #3 |
IPv6-only |
|
Source Port |
60000 |
Not significant for IP packet classification |
|
Destination Port |
60000 |
Value does not match with reference packet filter #2. Reference packet filter #3 can match all values of "Destination port" |
Table 10.3.1.3.3-3: Condition for IP packet contents (step 4, Table 10.3.1.3.2-1)
Condition |
Explanation |
IPv6-only |
This condition applies if the test variable IP type is set to ‘IPv6’ |