7.2.3 Acknowledged mode
36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification
7.2.3.1 AM RLC / Concatenation and reassembly
7.2.3.1.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { The UE has multiple RLC SDUs in the transmission buffer that fits into the available AMD PDU size }
then { The UE concatenates the RLC SDUs in the transmission buffer into an AMD PDU and transmits it}
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { The UE receives an AMD PDUs containing concatenated RLC }
then { The UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators indicated in AMD PDUs }
}
7.2.3.1.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 36.322, clauses 4.2.1.3.2 , 4.2.1.3.3, 6.2.1.4 and 6.2.2.6.
[TS 36.322, clause 4.2.1.3.2]
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:
– segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.
…
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
….
– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
…
[TS 36.322, clause 6.2.1.4]
AMD PDU consists of a Data field and an AMD PDU header.
AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).
An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI.
Figure 6.2.1.4-1: AMD PDU (No LI)
Figure 6.2.1.4-2: AMD PDU (Odd number of LIs, i.e. K = 1, 3, 5, …)
Figure 6.2.1.4-3: AMD PDU (Even number of LIs, i.e. K = 2, 4, 6, …)
[TS 36.322, clause 6.2.2.6]
The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.
Table 6.2.2.6-1: FI field interpretation
Value |
Description |
00 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
01 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
10 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
11 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
7.2.3.1.3 Test description
7.2.3.1.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.1.3.1-1.
Table 7.2.3.1.3.1-1: RLC settings
Parameter |
Value |
t-StatusProhibit |
500 ms |
7.2.3.1.3.2 Test procedure sequence
Table 7.2.3.1.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
2 |
The SS transmits an AMD PDU including two RLC SDUs of size 40 bytes each with poll bit set to ‘1’. |
<– |
AMD PDU(AMD PDU header(D/C=’1’, RF=’0’, P=’1’, FI=’00’,E=’1’, SN=’0’,E1=’0’, LI1=’40’ bytes), 2 RLC SDUs of 40 bytes) |
– |
– |
3 |
The SS waits for 60 ms and the allocates an UL grant (UL grant allocation type 3) of size 776 bits (Note 1). |
<– |
(UL grant, 776 bits) |
– |
– |
4 |
Check: Does the UE transmit a STATUS PDU with positive acknowledgement? |
–> |
STATUS PDU (ACK SN=1) |
2 |
P |
5 |
Check: Does the UE transmit two RLC SDUs within an AMD PDU with FI field set to ‘00’, first E field in the fixed part set to ‘1’, first E field in the extension part set to ‘0’, first LI field set to 20 bytes? |
–> |
AMD PDU(AMD PDU header(P=’1’, FI=’00’, E=’1’,SN=0, E1=’0’, LI1=’40’) ), two RLC SDUs of size 40 bytes) |
1, 2 |
P |
6 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
7 |
After 500 ms the SS transmits an AMD PDU including three RLC SDU of size 20 bytes with P field set to "1". |
<– |
AMD PDU(AMD PDU header(D/C=’1’, RF=’0’, P=’1’, FI=’00’,E=’1’, SN=’1’, E1=’1’, LI1=’ 20’ bytes, E2=’0’, LI2=’40’ bytes), three RLC SDUs of size 20 bytes) |
– |
– |
8 |
The SS waits for 60 ms and then allocates an UL grant (UL grant allocation type 3) of size 680 bits. (Note 2). |
<– |
(UL grant, 680 bits) |
– |
– |
9 |
Check: Does the UE transmit a STATUS PDU with positive acknowledgement? |
–> |
STATUS PDU (ACK SN=2) |
2 |
P |
10 |
Check: Does the UE transmit three RLC SDUs within an AMD PDU with FI field set to “00”, first E field in the fixed part set to ‘1’, first E field in the extension part set to ‘1’, first LI field set to 20 bytes, second E field in the extension part set to ‘0’, second LI field set to 20 bytes and P field set to “1”? |
–> |
AMD PDU(AMD PDU header(P=’1’, FI=’00’, SN=1, E1=’1’, LI1=’20’, E2=’0’, LI2=’20’), three RLC SDUs of size 20 bytes) |
1, 2 |
P |
11 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
Note 1 UL grant of 776 bits (ITBS=11, NPRB=4, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will fit two RLC SDUs of 40 bytes within one AMD PDU. MAC PDU of 776 bits=97 bytes fits an AMD PDU payload of 80 bytes (two 40 byte RLC SDUs) + 4 bytes AMD PDU header + 13 bytes spare for MAC header and possible RLC STATUS PDU and BSR report. Note 2 UL grant of 680 bits (ITBS=8, NPRB=5, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will fit three RLC SDUs of 20 bytes within one AMD PDU. MAC PDU of 680 bits=85 bytes fits an AMD PDU payload of 60 bytes (three 20 byte RLC SDUs) + 5 bytes AMD PDU header + 20 bytes spare for MAC header and possible RLC STATUS PDU and BSR report. |
7.2.3.1.3.3 Specific message contents
None.
7.2.3.2 AM RLC / Segmentation and reassembly / No PDU segmentation
7.2.3.2.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { the UE has a RLC SDU with larger size than available AMD PDU size in the transmission buffer }
then { the UE segments the RLC SDU in accordance with the available AMD PDU size }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { the UE receives AMD PDUs containing a segmented RLC SDU }
then { the UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators indicated in the AMD PDUs }
}
7.2.3.2.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 36.322, clauses 4.2.1.3.2, 4.2.1.3.3 and 6,2.2.6.
[TS 36.322, clause 4.2.1.3.2]
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:
– segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.
…
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
….
– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
…
[TS 36.322, clause 6.2.2.6]
…
The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.
Table 6.2.2.6-1: FI field interpretation
Value |
Description |
00 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
01 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
10 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
11 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
7.2.3.2.3 Test description
7.2.3.2.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18].
7.2.3.2.3.2 Test procedure sequence
Table 7.2.3.2.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
1 |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
2 |
The SS transmits a RLC SDU of size 80 bytes segmented into two AMD PDUs. The two AMD PDUs are transmitted in separate TTIs. |
<– |
(RLC SDU#1) AMD PDU#1(FI=’01’,SN=0) AMD PDU#2(FI=’10’,SN=1) |
– |
– |
3 |
60 ms after step 2 the SS allocates 2 UL grants (UL grant allocation type 2) with a time spacing of 10 ms of size 392 bits. (Note 1, Note 3). |
<– |
(UL grants) |
– |
– |
4 |
Check: Does the UE return a RLC SDU with equal content as sent in downlink in step 2 segmented into two AMD PDUs and received in different TTIs? (Note2: Details for AMD PDU#2) |
–> |
(RLC SDU#1) AMD PDU#1 AMD PDU#2 |
1,2 |
P |
5 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
6 |
The SS sends a RLC SDU of size 120 bytes octets segmented into three AMD PDUs. |
<– |
(RLC SDU#2) AMD PDU#1(FI=’01’,SN=2) AMD PDU#2(FI=’11’,SN=3) AMD PDU#3(FI=’10’,SN=4) |
– |
– |
7 |
60 ms after step 6 the SS allocates 3 UL grants (UL grant allocation type 2) with a time spacing of 10 ms of size 392 bits. (Note 1, Note 3). |
<– |
(UL grants) |
– |
– |
8 |
Check: Does the UE return a RLC SDU with equal content as sent in downlink in step 6 segmented into three AMD PDUs where each AMD PDU is received in different TTI? (Note2: Details for AMD PDU#3) |
–> |
(RLC SDU#2) AMD PDU#1 AMD PDU#2 AMD PDU#3 |
1,2 |
P |
9 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=5) |
– |
– |
Note 1: UL grant of 392 bits (ITBS=8, NPRB=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen to force the UE to segment the returned UL RLC SDU into multiple AMD PDUs. An UL grant of 392 bits=49 bytes allows the UE to transmit one AMD PDU of maximum 46 bytes (49 bytes – 2 byte AMD PDU header – minimum 1 byte MAC header). UE at step 4 and step 8 during transmission of AMD PDU#1 will transmit BSR MCE which will take 2 bytes and hence AMD PDU size will be 44 bytes. Note 2: Polling bit will be set for this PDU by the UE and SS transmits a STATUS PDU. Note 3: The SS transmits UL grant to the UE at every 10 ms to provide the necessary time division of the UE DL receptions and UL transmissions for UE operating in FDD type B half-duplex mode. See TS 36.523-3 sub-clause 7.26 for scheduling pattern for type B half-duplex FDD UE. |
7.2.3.2.3.3 Specific message contents
None.
7.2.3.3 AM RLC / Segmentation and reassembly / Framing info field
7.2.3.3.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 00 }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 01 }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 11 }
then { UE correctly decodes the received AMD PDU or AMD PDU segment}
}
(4)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 10 }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
7.2.3.3.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 6.2.2.6.
[TS 36.322, clause 6.2.2.6]
Length: 2 bits.
The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field is provided in Table 6.2.2.6-1.
Table 6.2.2.6-1: FI field interpretation
Value |
Description |
00 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
01 |
First byte of the Data field corresponds to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
10 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field corresponds to the last byte of a RLC SDU. |
11 |
First byte of the Data field does not correspond to the first byte of a RLC SDU. Last byte of the Data field does not correspond to the last byte of a RLC SDU. |
7.2.3.3.3 Test description
7.2.3.3.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18].
7.2.3.3.3.2 Test procedure sequence
Table 7.2.3.3.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits AMD PDU#1 containing a complete RLC SDU#1 (FI field = 00). |
<– |
AMD PDU#1 |
– |
– |
2 |
Check: Does the UE transmit RLC SDU#1? |
–> |
(RLC SDU#1) |
1 |
P |
2A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
3 |
The SS transmits AMD PDU#2 containing the first segment of RLC SDU#2 (FI field = 01). |
<– |
AMD PDU#2 |
– |
– |
4 |
The SS transmits AMD PDU#3 containing the second segment of RLC SDU#2 (FI field = 11). |
<– |
AMD PDU#3 |
– |
– |
5 |
The SS transmits AMD PDU#4 containing the last segment of RLC SDU#2 (FI field = 10). |
<– |
AMD PDU#4 |
– |
– |
6 |
Check: Does the UE transmit RLC SDU#2? |
–> |
(RLC SDU#2) |
2,3,4 |
P |
6A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
7 |
The t-PollRetransmit timer for RLC PDU#5 expires and SS assumes that the transmission of AMD PDU#5 containing a complete RLC SDU#3 and a complete RLC SDU#4 is failed and consider RLC PDU#5 for re-transmission |
– |
– |
– |
– |
8 |
The SS transmits AMD PDU segment containing a complete RLC SDU#3 (FI field = 00). |
<– |
AMD PDU segment |
– |
– |
9 |
Check: Does the UE transmit RLC SDU#3? |
–> |
(RLC SDU#3) |
1 |
P |
9A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=3) |
– |
– |
10 |
The SS transmits AMD PDU segment containing the first segment of RLC SDU#4 (FI field = 01). |
<– |
AMD PDU segment |
– |
– |
11 |
The SS transmits AMD PDU segment containing the second segment of RLC SDU#4 (FI field = 11). |
<– |
AMD PDU segment |
– |
– |
12 |
The SS transmits AMD PDU segment containing the last segment of RLC SDU#4 (FI field = 10). |
<– |
AMD PDU segment |
– |
– |
13 |
Check: Does the UE transmit RLC SDU#4? |
–> |
(RLC SDU#4) |
2,3,4 |
P |
14 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=4) |
– |
– |
7.2.3.3.3.3 Specific message contents
None.
7.2.3.4 AM RLC / Segmentation and reassembly / Different numbers of length indicators
7.2.3.4.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment with no LI field }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment with one LI field }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU or an AMD PDU segment with two LI fields }
then { UE correctly decodes the received AMD PDU or AMD PDU segment }
}
7.2.3.4.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 6.2.2.5.
[TS 36.322, clause 6.2.2.5]
Length: 11 bits.
The LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU delivered/received by an UM or an AM RLC entity. The first LI present in the RLC DATA PDU header corresponds to the first Data field element present in the Data field of the RLC DATA PDU, the second LI present in the RLC DATA PDU header corresponds to the second Data field element present in the Data field of the RLC DATA PDU, and so on. The value 0 is reserved.
7.2.3.4.3 Test description
7.2.3.4.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.4.3.1-1.
Table 7.2.3.4.3.1-1: RLC settings
Parameter |
Value |
t-Reordering |
150 ms |
7.2.3.4.3.2 Test procedure sequence
Table 7.2.3.4.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
1 |
The SS transmits AMD PDU#1 containing a complete RLC SDU#1 without LI field. |
<– |
AMD PDU#1 |
– |
– |
2 |
The SS transmits an uplink grant allowing the UE to transmit 1 RLC SDU. |
<– |
(UL grant) |
– |
– |
3 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#1? |
–> |
AMD PDU (RLC SDU#1) |
1 |
P |
3A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
4 |
The SS transmits AMD PDU#2 containing a complete RLC SDU#2 and a complete RLC SDU#3 with one LI field. |
<– |
AMD PDU#2 |
– |
– |
5 |
The SS waits for 60 ms then assigns an UL grant sufficient for the UE to loopback RLC SDU#2 and RLC SDU#3. |
<– |
(UL grant) |
– |
– |
6 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#2 and RLC SDU#3 in its data field? |
–> |
AMD PDU (RLC SDU#2, RLC SDU#3) |
2 |
P |
7 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
8 |
The SS transmits AMD PDU#3 containing a complete RLC SDU#4, a complete RLC SDU#5 and a complete RLC SDU#6 with two LI fields. |
<– |
AMD PDU#3 |
– |
– |
9 |
The SS waits for 60 ms then assigns an UL grant sufficient for the UE to loopback RLC SDU#4, RLC SDU#5 and RLC SDU#6. |
<– |
(UL grant) |
– |
– |
10 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#4, RLC SDU#5 and RLC SDU#6 in its data field? |
–> |
AMD PDU (RLC SDU#4, RLC SDU#5, RLC SDU#6) |
3 |
P |
11 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=3) |
– |
– |
12 |
Void |
– |
– |
– |
– |
13 |
The t-PollRetransmit timer for AMD PDU#4 expires and SS assumes that the transmission of AMD PDU#4 containing a complete RLC SDU#7, a complete RLC SDU#8, a complete RLC SDU#9, a complete RLC SDU#10, a complete RLC SDU#11 and a complete RLC SDU#12 is failed and consider AMD PDU#4 for re-transmission. |
– |
– |
– |
– |
14 |
The SS transmits AMD PDU segment containing a complete RLC SDU#7 without LI field. |
<– |
AMD PDU segment |
– |
– |
15 |
The SS waits for 60 ms and then assigns an uplink grant (UL grant allocation type 3) allowing the UE to transmit 1 RLC SDU. |
<– |
(UL grant) |
– |
– |
16 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#7? |
–> |
AMD PDU (RLC SDU#7) |
1 |
P |
16A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=4) |
– |
– |
17 |
The SS transmits AMD PDU segment containing a complete RLC SDU#8 and a complete RLC SDU#9 with one LI field. |
<– |
AMD PDU segment |
– |
– |
18 |
The SS waits for 60 ms and then assigns an UL grant (UL grant allocation type 3) sufficient for the UE to loopback RLC SDU#8 and RLC SDU#9. |
<– |
(UL grant) |
– |
– |
19 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#8 and RLC SDU#9 in its data field? |
–> |
AMD PDU (RLC SDU#8, RLC SDU#9) |
2 |
P |
20 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=5) |
– |
– |
21 |
The SS transmits AMD PDU segment containing a complete RLC SDU#10, a complete RLC SDU#11 and a complete RLC SDU#12 with two LI fields. |
<– |
AMD PDU segment |
– |
– |
22 |
The SS waits for 60 ms and then assigns an UL grant (UL grant allocation type 3) sufficient for the UE to loopback RLC SDU#10, RLC SDU#11 and RLC SDU#12. |
<– |
(UL grant) |
– |
– |
23 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#10, RLC SDU#11 and RLC SDU#12 in its data field? |
–> |
AMD PDU (RLC SDU#10, RLC SDU#11, RLC SDU#12) |
3 |
P |
24 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=6) |
– |
– |
25 |
Void |
– |
– |
– |
– |
7.2.3.4.3.3 Specific message contents
None.
7.2.3.5 AM RLC / Reassembly / LI value > PDU size
7.2.3.5.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives PDU with "Length Indicators" that point beyond the end of the PDU }
then { UE discards PDU }
}
7.2.3.5.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.5.1 and 6.2.2.5.
[TS 36.322, clause 5.5.1]
When an RLC entity receives an RLC PDU that contains reserved or invalid values, the RLC entity shall:
– discard the received PDU.
[TS 36.322, clause 6.2.2.5]
Length: 11 bits.
The LI field indicates the length in bytes of the corresponding Data field element present in the RLC data PDU. The first LI present in the RLC data PDU header corresponds to the first Data field element present in the Data field of the RLC data PDU, the second LI present in the RLC data PDU header corresponds to the second Data field element present in the Data of the RLC data PDU, and so on. The value 0 is reserved.
7.2.3.5.3 Test description
7.2.3.5.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18].
7.2.3.5.3.2 Test procedure sequence
Table 7.2.3.5.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
0 |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
1 |
The SS transmits an AMD PDU containing the first half (10 bytes) of SDU#1 in its data field to the UE. |
<– |
AMD PDU#1 (SN = 0) |
– |
– |
2 |
The SS transmits an AMD PDU containing the second half (10 bytes) of SDU#1 and the first half (10 bytes) of SDU#2 in its data field to the UE. LI associated with PDU#2 has a value > PDU size, i.e. > 20. |
<– |
AMD PDU#2 (SN=1) |
– |
– |
3 |
The SS transmits an AMD PDU containing the second half (10 bytes) of SDU#2 and the first half (10 bytes) of SDU#3 in its data field to the UE. |
<– |
AMD PDU#3 (SN=2) |
– |
– |
4 |
The SS transmits an AMD PDU containing the second half (10 bytes) of SDU#3 in its data field to the UE. |
<– |
AMD PDU#4 (SN=3) |
– |
– |
4A |
100 ms after step 4 t he SS assigns an UL grant (UL grant allocation type 3) of size 56 bits (Note 1). |
<– |
(UL grant, 56 bits) |
– |
– |
5 |
Check: Does the UE transmit a STATUS PDU with NACK_SN field set to 1? |
–> |
STATUS PDU |
1 |
P |
6 |
The SS transmits an AMD PDU containing the second half (10 bytes) of SDU#1 and the first half (10 bytes) of SDU#2 in its data field to the UE. The LI is correct. |
<– |
AMD PDU#2 (SN=1) |
– |
– |
6A |
The SS waits for 60 ms to ensure UE RLC has all the required SDU available in UL for loopback. |
||||
6B |
The SS transmits an UL grant (UL grant allocation type 3) of size 744 bits (Note 2). |
<– |
(UL grant, 744 bits) |
– |
– |
7 |
Check: Does the UE transmit RLC SDU#1, SDU#2, and SDU#3? (Note 3: Details for RLC PDU carrying RLC SDU#3) |
–> |
AMD PDU(RLC SDU#1, RLC SDU#2, RLC SDU#3) |
1 |
P |
8 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
Note 1: UL grant of 56 bits (ITBS=1, NPRB=2, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will be enabled to send the status PDU. Note 2: UL grant of 744 bits (ITBS=13, NPRB=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will fit all 3 SDU in one AMD PDU. Note 3: In step 7, poll is set so SS will send STATUS PDU to UE in step 8. |
7.2.3.5.3.3 Specific message contents
None.
7.2.3.6 AM RLC / Correct use of sequence numbering
7.2.3.6.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE transmits the first PDU }
then { UE sets the Sequence Number field equal to 0 }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE transmits subsequent PDUs }
then { SN incremented by 1 for each PDU transmitted }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE transmits more than 1024 PDUs }
then { UE wraps the Sequence Number after transmitting the 1024 PDU }
}
(4)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { more than 1024 PDUs are sent to UE }
then { UE accepts PDUs with SNs that wrap around every 1024 PDU }
}
7.2.3.6.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.1.3.1.1, 6.2.2.3 and 7.1.
[TS 36.322, clause 5.1.3.1.1]
The transmitting side of an AM RLC entity shall prioritize transmission of RLC control PDUs over RLC data PDUs. The transmitting side of an AM RLC entity shall prioritize retransmission of RLC data PDUs over transmission of new AMD PDUs.
The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) and VT(MS) as follows:
– a SN falls within the transmitting window if VT(A) <= SN < VT(MS);
– a SN falls outside of the transmitting window otherwise.
The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside of the transmitting window.
When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall:
– set the SN of the AMD PDU to VT(S), and then increment VT(S) by one.
The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful reception by its peer AM RLC entity) for a RLC data PDU by the following:
– STATUS PDU from its peer AM RLC entity.
When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC entity shall:
– set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) <= SN <= VT(S) and for which a positive acknowledgment has not been received yet.
– if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU :- send an indication to the upper layers of successful delivery of the RLC SDU.
[TS 36.322, clause 6.2.2.3]
Length: 10bits for AMD PDU, AMD PDU segments and STATUS PDUs. …
The SN field indicates the sequence number of the corresponding … AMD PDU. For an AMD PDU segment, the SN field indicates the sequence number of the original AMD PDU from which the AMD PDU segment was constructed from. The sequence number is incremented by one for every … AMD PDU.
[TS 36.322, clause 7.1]
…
All state variables and all counters are non-negative integers.
All state variables related to AM data transfer can take values from 0 to 1023. All arithmetic operations contained in the present document on state variables related to AM data transfer are affected by the AM modulus (i.e. final value = [value from arithmetic operation] modulo 1024).
AMD PDUs … are numbered integer sequence numbers (SN) cycling through the field: 0 to 1023 for AMD PDU …
…
c) VT(S) – Send state variable
This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU. It is initially set to 0, and is updated whenever the AM RLC entity delivers an AMD PDU with SN = VT(S).
…
7.2.3.6.3 Test description
7.2.3.6.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– UE is in state Loopback Activated (state 4) according to [18].
7.2.3.6.3.2 Test procedure sequence
Table 7.2.3.6.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
– |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
– |
EXCEPTION: SS is configured 500ms in advance for step 1 and 2. Step 1 is executed 512 times such that 1 AMD PDU is transmitted every second radio frame. (Note 1) . Step 2 is started 60 ms after the first DL AMD PDU has been transmitted in step 1 (Note 1). |
– |
– |
– |
– |
– |
EXCEPTION: In parallel to steps 1 and 2, the behaviour described in table 7.2.3.6.3.2-2 is running. |
– |
– |
– |
– |
1 |
The SS transmits an AMD PDU to the UE. SN equals 0 and is incremented for each PDU transmitted (Note 1). |
<– |
AMD PDU |
– |
– |
2 |
The SS transmits 1 UL grant (UL grant allocation type 2) in every second radio frame to enable the UE to return each received AMD PDU in one looped back AMD PDU (Note 1). |
<– |
(UL grants) |
– |
– |
2A |
The SS does not allocate any uplink grant. |
– |
– |
– |
– |
– |
EXCEPTION: SS is configured 500ms in advance for step 2B and 2C.Step 2B is executed 512 times such that 1 AMD PDU is transmitted every second radio frame. (Note 1) . Step 2C is started 60 ms after the first DL AMD PDU has been transmitted in step 2B (Note 1). |
– |
– |
– |
– |
– |
EXCEPTION: In parallel to steps 2B and 2C, the behaviour described in table 7.2.3.6.3.2-3 is running. |
– |
– |
– |
– |
2B |
The SS transmits an AMD PDU to the UE. SN equals 512 and is incremented for each PDU transmitted. |
<– |
AMD PDU |
– |
– |
2C |
The SS transmits 1 UL grant (UL grant allocation type 2) in every second radio frame to enable the UE to return each received AMD PDU in one looped back AMD PDU (Note 1). . |
<– |
(UL grants) |
– |
– |
3 |
The SS transmits an AMD PDU to the UE. SN equals 0. |
<– |
AMD PDU |
– |
– |
4 |
Void |
– |
– |
– |
– |
4A |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
5 |
Check: Does the UE transmit an AMD PDU with SN=0? |
–> |
AMD PDU |
3,4 |
P |
6 |
The SS transmits a STATUS PDU with ACK_SN = 1. |
<– |
STATUS PDU |
– |
– |
Note 1: 20 ms gap between transmissions both in DL and UL respectively allows TTCN to tolerate one HARQ retransmission (FDD/TDD) per transport block, if such happen (TS 36.523-3). Note 2: Delaying first UL grant for 60 ms, ensures that UE UL buffer does not become empty every time one UL AMD PDU is sent i.e. UE does not enable polling for every UL AMD PDU. SS continuously transmits the grants until it has received all PDUs in UL. |
Table 7.2.3.6.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit an AMD PDU with SN = 0? |
–> |
AMD PDU |
1 |
P |
– |
EXCEPTION: Steps 2 and 3a1 are executed 511 times. |
– |
– |
– |
– |
2 |
Check: Does the UE transmit an AMD PDU with SN increased by 1 compared with the previous one? |
–> |
AMD PDU |
2 |
P |
EXCEPTION: Step 3a1 describes behaviour that depends on the contents of the AMD PDU transmitted at Step 2. |
– |
– |
– |
– |
|
3a1 |
IF the UE has set the poll bit in the AMD PDU transmitted at Step 2 THEN the SS transmits a Status Report. |
<– |
STATUS PDU |
– |
– |
Table 7.2.3.6.3.2-3: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Steps 1 and 2a1 are executed 512 times. |
– |
– |
– |
– |
1 |
Check: Does the UE transmit an AMD PDU with SN increased by 1 compared with the previous one? |
–> |
AMD PDU |
2 |
P |
EXCEPTION: Step 2a1 describes behaviour that depends on the contents of the AMD PDU transmitted at Step 1. |
– |
– |
– |
– |
|
2a1 |
IF the UE has set the poll bit in the AMD PDU transmitted at Step 1 THEN the SS transmits a Status Report. |
<– |
STATUS PDU |
– |
– |
7.2.3.6.3.3 Specific message contents
None.
7.2.3.7 AM RLC / Control of transmit window
7.2.3.7.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state with DRB established and pending uplink data for transmission}
ensure that {
when { AMD PDUs in transmission buffer fall outside VT(A) <= SN < VT(MS) }
then { UE does not transmit these AMD PDUs }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state with DRB established and pending uplink data for transmission }
ensure that {
when { receiving a STATUS PDU where ACK_SN acknowledges at least one AMD PDU not yet acknowledged }
then { UE transmits AMD PDUs within updated window range}
}
7.2.3.7.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.1.3.1.1, 7.1 and 7.2.
[TS 36.322, clause 5.1.3.1.1]
…
The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) and VT(MS) as follows:
– a SN falls within the transmitting window if VT(A) <= SN < VT(MS);
– a SN falls outside of the transmitting window otherwise.
The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside of the transmitting window.
When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall:
– set the SN of the AMD PDU to VT(S), and then increment VT(S) by one.
The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful reception by its peer AM RLC entity) for a RLC data PDU by the following:
– STATUS PDU from its peer AM RLC entity.
When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC entity shall:
– set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) <= SN <= VT(S) and for which a positive acknowledgment has not been received yet.
– if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU :
– send an indication to the upper layers of successful delivery of the RLC SDU.
[TS 36.322, clause 7.2]
a) AM_Window_Size
This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512.
…
[TS 36.322, clause 7.1]
…
a) VT(A) – Acknowledgement state variable
This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be received in-sequence, and it serves as the lower edge of the transmitting window). It is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A).
b) VT(MS) – Maximum send state variable
This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window.
…
7.2.3.7.3 Test description
7.2.3.7.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– UE is in state Loopback Activated (state 4) according to [18] with the loopback size set to 100 bytes, and with the expectations listed in table 7.2.3.7.3.1-1.
Table 7.2.3.7.3.1-1: RLC Settings
Parameter |
Value |
PollPDU |
pInfinity |
PollByte |
kBinfinity |
t-PollRetransmit |
ms300 |
Table 7.2.3.7.3.1-2: SchedulingRequest-Config
Derivation Path: 36.508 Table 4.6.3-20 |
|||
Information Element |
Value/remark |
Comment |
Condition |
dsr-TransMax |
n8 |
7.2.3.7.3.2 Test procedure sequence
Table 7.2.3.7.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
The SS does not allocate any uplink grant. |
– |
– |
– |
– |
– |
EXCEPTION: The SS is configured for step 1 and 1A 500ms in advance. Step 1 is repeated W+1 times, where W = AM_Window_Size. The transmission is performed every second radio frame. (Note 2). Step 1A is started 100 ms after the first DL AMD PDU has been transmitted in step 1. |
– |
– |
– |
– |
– |
EXCEPTION: In parallel to steps 1 and 1A, the behaviour described in table 7.2.3.7.3.2-2 is running. |
– |
– |
– |
– |
1 |
The SS transmits an AMD PDU containing a SDU to the UE. |
<– |
AMD PDU |
– |
– |
1A |
In the following steps the SS transmits 1 UL grant (UL grant allocation type 2) in every second radio frame to enable the UE to return each received AMD PDU in one looped back AMD PDU. (Note 2) |
<– |
(UL grants) |
– |
– |
1B |
Void |
– |
– |
– |
– |
1C |
Check: Does the UE transmit an AMD PDU with the Poll bit set and with the contents of the SDU? |
–> |
AMD PDU(SN=W-1), Poll |
1 |
P |
1D |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
2 |
Check: Does the UE transmit an AMD PDU within t-PollRetransmit/2? |
–> |
AMD PDU |
1 |
F |
3 |
The SS transmits a STATUS PDU to acknowledge the W uplink AMD PDUs with SN=0 to SN=W-1. ACK_SN = W. |
<– |
STATUS PDU |
– |
– |
3A |
Check: Does the UE transmit an AMD PDU with the Poll bit set and with the contents of the SDU? |
–> |
AMD PDU(SN=W), Poll |
2 |
P |
3B |
The SS transmits a STATUS PDU with ACK_SN = W+1. |
<– |
STATUS PDU |
– |
– |
Note 1: SDUs are numbered 1,2, …, W+1 Note 2: 20 ms gap between transmissions both in DL and UL respectively allows TTCN to tolerate one HARQ retransmission (FDD/TDD) per transport block, if such happen (TS 36.523-3). |
Table 7.2.3.7.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
EXCEPTION: Step 1 is executed W-1 times. |
– |
– |
– |
– |
1 |
The UE transmits an AMD PDU with the same data as received in the corresponding DL AMD PDU. |
–> |
AMD PDU |
– |
– |
7.2.3.7.3.3 Specific message contents
None.
7.2.3.8 AM RLC / Control of receive window
7.2.3.8.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { the UE receives AMD PDUs with SN outside the upper boundary of the receive window }
then { the UE discards these AMD PDUs }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { the receive window has been moved }
then { UE continues accepting AMD PDUs within updated window range }
}
7.2.3.8.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.1.3.2.1 and 7.2.
[TS 36.322, clause 5.1.3.2.1]
The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and VR(MR) as follows:
– a SN falls within the receiving window if VR(R) <= SN < VR(MR);
– a SN falls outside of the receiving window otherwise.
When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall:
– either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1.3.2.2);
– if the received RLC data PDU was placed in the reception buffer:
– update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t-Reordering as needed (see sub clause 5.1.3.2.3).
When t-Reordering expires, the receiving side of an AM RLC entity shall:
– update state variables and start t-Reordering as needed (see sub clause 5.1.3.2.4).
[TS 36.322, clause 7.2]
a) AM_Window_Size
This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512.
…
7.2.3.8.3 Test description
7.2.3.8.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with a loopback size of 0 byte.
7.2.3.8.3.2 Test procedure sequence
Table 7.2.3.8.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
– |
EXCEPTION: SS is configured 500ms in advance for step 1. Step 1 shall be repeated W times, where W is AM_Window_Size. Polling bit enabled for the Wth RLC PDU transmitted. The SS shall set the Sequence Number field for the first AMD PDU to 0 and increment it by 1 for every execution of Step 1. The transmission is performed in every second radio frame.(Note 3) |
– |
– |
– |
– |
1 |
The SS transmits an AMD PDU to the UE |
<– |
AMD PDU |
||
2 |
Check: Does the UE transmit a STATUS PDU acknowledging W PDUs? (ACK_SN = W) |
–> |
STATUS PDU |
1 |
P |
3 |
The SS transmits the (W+1)th AMD PDU to the UE with the Sequence Number field set to ((2W mod 1024) = 0) and the Polling bit set. |
<– |
AMD PDU |
– |
– |
4 |
Check: does the UE transmit a STATUS PDU acknowledging W PDUs? (ACK_SN = W) (Note 1) |
–> |
STATUS PDU |
1 |
P |
5 |
The SS transmits the (W+2)th AMD PDU to the UE with the Sequence Number field set to W and the Polling bit set. |
<– |
AMD PDU |
– |
– |
6 |
Check: Does the UE transmit a STATUS PDU acknowledging W +1 PDUs? (ACK_SN field = W+1) (Note 2) |
–> |
STATUS PDU |
2 |
P |
Note 1: This shows that the UE has discarded the (W+1)th PDU. Note 2: This shows that the UE did not discard the (W+2)th PDU and has updated the Receive Window correctly. Note 3: 20 ms gap between transmissions both in DL and UL respectively allows TTCN to tolerate one HARQ retransmission (FDD/TDD) per transport block, if such happen (TS 36.523-3). |
7.2.3.8.3.3 Specific message contents
None.
7.2.3.9 AM RLC / Polling for status
7.2.3.9.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { last data in the buffer was transmitted }
then { UE transmits a Poll }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { the t-PollRetransmit timer expires }
then { UE transmits a Poll }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { PDU_WITHOUT_POLL=pollPDU }
then { UE transmits a Poll }
}
(4)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { BYTE_WITHOUT_POLL=pollByte }
then { UE transmits a Poll }
}
7.2.3.9.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.2.2.
[TS 36.322, clause 5.2.2]
…
Upon assembly of a new AMD PDU, the transmitting side of an AM RLC entity shall:
– increment PDU_WITHOUT_POLL by one;
– increment BYTE_WITHOUT_POLL by every new byte of Data field element that it maps to the Data field of the RLC data PDU;
– if PDU_WITHOUT_POLL >= pollPDU; or
– if BYTE_WITHOUT_POLL >= pollByte;
– include a poll in the RLC data PDU as described below.
Upon assembly of an AMD PDU or AMD PDU segment, the transmitting side of an AM RLC entity shall:
– if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data PDU awaiting for acknowledgements) after the transmission of the RLC data PDU; or
– if no further RLC data PDU can be transmitted after the transmission of the RLC data PDU (e.g. due to window stalling);
– include a poll in the RLC data PDU as described below.
To include a poll in a RLC data PDU, the transmitting side of an AM RLC entity shall:
– set the P field of the RLC data PDU to "1";
– set PDU_WITHOUT_POLL to 0;
– set BYTE_WITHOUT_POLL to 0;
After delivering a RLC data PDU including a poll to lower layer and after incrementing of VT(S) if necessary, the transmitting side of an AM RLC entity shall:
– set POLL_SN to VT(S) – 1;
– if t-PollRetransmit is not running:
– start t-PollRetransmit;
– else:
– restart t-PollRetransmit;
[TS 36.322, clause 5.2.2.3]
Upon expiry of t-PollRetransmit, the transmitting side of an AM RLC entity shall:
– if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC data PDU awaiting for acknowledgements); or
– if no new RLC data PDU can be transmitted (e.g. due to window stalling):
– consider the AMD PDU with SN = VT(S) – 1 for retransmission;
– consider any AMD PDU which has not been positively acknowledged for retransmission;
– include a poll in a RLC data PDU as described in section 5.2.2.1.
7.2.3.9.3 Test description
7.2.3.9.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.9.3.1-1 and 7.2.3.9.3.1-2.
Table 7.2.3.9.3.1-1: RLC Settings
Parameter |
Value |
pollPDU |
p256 |
pollByte |
kB25 |
t-PollRetransmit |
ms400 |
Table 7.2.3.9.3.1-2: SchedulingRequest-Config
Derivation Path: 36.508 Table 4.6.3-20 |
|||
Information Element |
Value/remark |
Comment |
Condition |
dsr-TransMax |
n8 |
7.2.3.9.3.2 Test procedure sequence
Table 7.2.3.9.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
0 |
During the whole test sequence, the SS should not allocate UL grants unless when explicitly stated so in the procedure. |
– |
– |
– |
– |
1 |
The SS transmits 4 AMD PDUs such that 1 AMD PDU is sent every second radio frame, each containing an RLC SDU of 960 bits. (Note 2) |
<– |
AMD PDU (SN=0) AMD PDU (SN=1) AMD PDU (SN=2) AMD PDU (SN=3) |
– |
– |
– |
EXCEPTION: In parallel to the events described in step 1A, the step specified in Table 7.2.3.9.3.2-2 should take place. |
– |
– |
– |
– |
1A |
The SS waits for 100 ms after the first DL AMD PDU has been transmitted in step 1, then starts assigning UL grants (UL grant allocation type 2) in every second radio frame of size 1000 bits. (Note 1) (Note 2) |
– |
– |
– |
– |
2 |
Check 1: Does the UE transmit an AMD PDU with a SN in range 0 to 3 and P=1? Record time TB. Check 2: Is (TB – TA) = t-PollRetransmit? |
–> |
AMD PDU |
2 |
P |
2A |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
3 |
Upon receiving the Poll, the SS transmits an RLC Status Report. |
<– |
STATUS PDU |
– |
– |
4 |
Check: Does the UE retransmit an AMD PDU within 1 sec? |
–> |
AMD PDU |
2 |
F |
5 |
SS performs an RRC Connection Reconfiguration procedure changing pollPDU to p4. |
– |
– |
– |
– |
5A |
The SS does not allocate any UL grant. |
– |
– |
– |
– |
6 |
The SS transmits 8 AMD PDUs such that 1 AMD PDU is sent every second radio frame, each containing an RLC SDU of 960 bits. (Note 2) |
<– |
AMD PDU (SN=4) AMD PDU (SN=5) … AMD PDU (SN=11) |
– |
– |
– |
EXCEPTION: In parallel to the events described in step 6A, the step specified in Table 7.2.3.9.3.2-3 should take place. |
– |
– |
– |
– |
6A |
The SS waits for 100 ms after the first DL AMD PDU has been transmitted in step 6, then starts assigning UL grants (UL grant allocation type 2) in every second radio frame of size 1000 bits. (Note 1) (Note 2) |
– |
– |
– |
– |
7 |
The SS transmits a Status Report with ACK_SN=12, NACK_SN=4, NACK_SN=5, NACK_SN=6, NACK_SN=8 and NACK_SN=9. |
<– |
STATUS PDU |
– |
– |
8 |
Check: Does the UE transmit AMD PDUs with the following SN and P values? AMD PDU, SN=4, P=0 AMD PDU, SN=5, P=0 AMD PDU, SN=6, P=0 AMD PDU, SN=8, P=0 AMD PDU, SN=9, P=1 |
–> |
AMD PDU (SN=4, P=0) AMD PDU (SN=5, P=0) AMD PDU (SN=6, P=0) AMD PDU (SN=8, P=0) AMD PDU (SN=9, P=1) |
3 |
P |
8AA |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
8A |
The SS transmits a Status Report with ACK_SN=12 and no NACK_SN. |
<– |
STATUS PDU |
– |
– |
9 |
SS performs an RRC Connection Reconfiguration procedure changing pollPDU to p256. |
– |
– |
– |
– |
9A |
The SS does not allocate any UL grant. |
– |
– |
– |
– |
10 |
After 500 ms the SS transmits 420 AMD PDUs such that 1 AMD PDU is sent every second radio frame, each containing an RLC SDU of size 960 bits. (Note 2) |
<– |
AMD PDU (SN=12) AMD PDU (SN=13) … AMD PDU (SN=431) |
– |
– |
– |
EXCEPTION: In parallel to the events described in step 10A, the steps specified in Table 7.2.3.9.3.2-4 should take place. |
– |
– |
– |
– |
10A |
The SS waits for 100 ms after the first DL AMD PDU has been transmitted in step 10, then starts assigning UL grants (UL grant allocation type 2) in every second radio frame of size 1000 bits. (Note 1) (Note 2) |
– |
– |
– |
– |
10B |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
Note 1: UL grant of 1000 bits (ITBS=13, NPRB=4, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to loop back one SDU of size 960 bits and one short BSR (8 bits) into each MAC PDU sent in the uplink (1000 bits – 16 bit AMD PDU header – 8 bit MAC BSR subheader – 8 bit MAC PDU subheader). The UE will include an SDU of size 960 bits and one short BSR in the looped back MAC PDU. Note 2: 20ms gap between transmissions both in DL and UL respectively allows TTCN to tolerate one HARQ retransmission (FDD/TDD) per transport block, if such happen (TS 36.523-3). |
Table 7.2.3.9.3.2-2: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit 4 AMD PDUs, with only the last one having the poll bit set? Record time TA when the PDU with the poll bit set is received at the SS. |
–> |
AMD PDUs |
1 |
P |
Table 7.2.3.9.3.2-3: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit 8 AMD PDUs, with the poll bit set only in the 4th and the 8th PDUs? |
–> |
AMD PDUs |
3 |
P |
Table 7.2.3.9.3.2-4: Parallel behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
Check: Does the UE transmit 209 AMD PDUs, with the poll bit set only in the last (209th) one? (Note 1) |
–> |
AMD PDUs |
1,4 |
P |
2 |
The SS transmits an RLC Status Report. |
<– |
STATUS PDU |
– |
– |
3 |
Check: Does the UE transmit 209 AMD PDUs, with the poll bit set only in the last (418th) one? (Note 1) |
–> |
AMD PDUs |
1,4 |
P |
4 |
The SS transmits an RLC Status Report. |
<– |
STATUS PDU |
– |
– |
5 |
Check: Does the UE transmit 2 AMD PDUs, with the poll bit set only in the last (420th ) one? |
–> |
AMD PDUs |
1,4 |
P |
6 |
The SS transmits an RLC Status Report. |
<– |
STATUS PDU |
– |
– |
Note 1: (960 bits x 209 PDUs) / 8 = 25 080 > 25 KB, with 1 kB = 1000 bytes (TS 36.331, cl. 3.2) |
7.2.3.9.3.3 Specific message contents
None.
7.2.3.10 AM RLC / Receiver status triggers
7.2.3.10.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { Reception failure of an RLC data PDU is detected }
then { UE initiates Status Reporting when t-Reordering expires }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { Status Reporting is triggered and t-StatusProhibit is running}
then { UE wait until t-StatusProhibit has expired to send Status Report }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { Polling from peer AM RLC entity is detected and the sequence number of the PDU that carries the Poll is less than VR(MS) }
then { UE initiates Status Reporting }
}
(4)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { Polling from peer AM RLC entity is detected and the sequence number of the PDU that carries the Poll is greater than or equal to VR(MS) }
then { UE waits until VR(MS) becomes greater than the sequence number of the PDU with the Poll before initiating Status Reporting }
}
(5)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { the UE needs to send a Status Report and the UL grant is not large enough to accommodate the whole report }
then { UE includes as many NACK SNs in the Status Report as allowed by the UL grant }
}
7.2.3.10.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.3.
[TS 36.322, clause 5.2.3]
An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative acknowledgements of RLC PDUs (or portions of them).
RRC configures whether or not the status prohibit function is to be used an AM RLC entity.
Triggers to initiate STATUS reporting include:
– Polling from its peer AM RLC entity:
– When a RLC data PDU with SN = x and the P field set to "1" is received from lower layer, the receiving side of an AM RLC entity shall:
– if the PDU is to be discarded as specified in subclause 5.1.3.2.2; or
– if x < VR(MS) or x >= VR(MR):
– trigger a STATUS report;
– else:
– delay triggering the STATUS report until x < VR(MS) or x >= VR(MR).
NOTE: This ensures that the RLC Status report is transmitted after HARQ reordering.
– Detection of reception failure of an RLC data PDU:
– The receiving side of an AM RLC entity shall trigger a STATUS report when t-Reordering expires.
NOTE: The expiry of T_reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after VR(MS) is updated.
When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall:
– if t-StatusProhibit is not running:
– at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to lower layer;
– else:
– at the first transmission opportunity indicated by lower layer after t-StatusProhibit expires, construct a single STATUS PDU even if status reporting was triggered several times while t-StatusProhibit was running and deliver it to lower layer;
When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall:
– start t-StatusProhibit.
When constructing a STATUS PDU, the AM RLC entity shall:
– for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in increasing SN order of PDUs and increasing byte segment order within PDUs, starting with SN = VR(R) up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU(s) indicated by lower layer:
– for an AMD PDU for which no byte segments have been received yet for an AMD PDU:
– include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU;
– for a continuous sequence of byte segments of a partly received AMD PDU that have not been received yet :
– include in the STATUS PDU a set of NACK_SN, SOstart and SOend
– set the ACK_SN to the SN of the next not received RLC Data PDU which is not indicated as missing in the resulting STATUS PDU.
7.2.3.10.3 Test description
7.2.3.10.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble
– The UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.10.3.1-1.
Table 7.2.3.10.3.1-1: RLC settings
Parameter |
Value |
t-Reordering |
ms150 |
t-StatusProhibit |
ms300 |
t-PollRetransmit |
ms500 |
Table 7.2.3.10.3.1-1A: MAC settings
Parameter |
Value |
Condition |
sr-ConfigIndex-r13 |
10 |
FDD |
7 |
TDD |
|
dsr-TransMax-13 |
n16 |
7.2.3.10.3.2 Test procedure sequence
Table 7.2.3.10.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
1 |
The SS transmits 4 AMD PDUs with SN=0, 1, 2, and 4. The SS sets the P field of all the AMD PDUs to 0. Record time TA when the AMD PDU with SN=4 is sent. |
<– |
AMD PDU (SN=0, P=0) AMD PDU (SN=1, P=0) AMD PDU (SN=2, P=0) AMD PDU (SN=4, P=0) |
– |
– |
1A |
The SS waits for 30 ms after the transmission of the last AMD PDU to ensure UE RLC has all the required SDUs available and then assigns 3 UL grants (UL grant allocation type 2) with a time spacing of 10 ms of size 840 bits (UL Grant Allocation type 2). (Note 1, Note 5, Note 6) |
<– |
(UL grants, 840 bits) |
– |
– |
1B |
The UE transmits RLC SDU#1. |
–> |
(RLC SDU#1) |
– |
– |
1C |
The UE transmits RLC SDU#2. |
–> |
(RLC SDU#2) |
– |
– |
1D |
The UE transmits RLC SDU#3. |
–> |
(RLC SDU#3) |
– |
– |
1E |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
1F |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
2 |
Check 1: Does the UE transmit a Status Report with NACK_SN=3 and ACK_SN=5? Record time TB Check 2: (TB – TA) = t-Reordering |
–> |
STATUS PDU |
1 |
P |
3 |
100 ms after the Status Report is received at Step 2, the SS transmits 4 AMD PDUs with SN=5, 6, 8 and 9. The SS sets the P field of all the AMD PDUs to 0. |
<– |
AMD PDU (SN=5, P=0) AMD PDU (SN=6, P=0) AMD PDU (SN=8, P=0) AMD PDU (SN=9, P=0) |
– |
– |
3A |
Void |
– |
– |
– |
– |
3B |
Check 1: Does the UE transmit a Status Report with NACK_SN=3, ACK_SN=7? Record time TC Check 2: (TC – TB) = t-StatusProhibit |
–> |
STATUS PDU |
2 |
P |
3C |
Void |
– |
– |
– |
– |
4 |
The UE transmit a Status Report with NACK_SN=3, NACK_SN=7 and ACK_SN=10 |
–> |
STATUS PDU |
||
4A |
The SS ignores scheduling requests unless otherwise specified and does not allocate any uplink grant and is configured for Uplink Grant Allocation Type 3. |
– |
– |
– |
– |
5 |
Void |
– |
– |
– |
– |
6 |
After 300 ms the SS transmits 2 AMD PDUs with SN=3, SN=7. The SS sets the P field of all the AMD PDUs to 0 except for that of the AMD PDU with SN=7. |
<– |
AMD PDU (SN=3, P=0) AMD PDU (SN=7, P=1) |
– |
– |
6A |
The SS waits for 50 ms after the transmission of the last AMD PDU to ensure UE RLC has all the required SDUs available and then assigns 1 UL grant (UL grant allocation type 3) of size 40 bits. (Note 2) |
<– |
(UL grant, 40 bits) |
– |
– |
7 |
Check: Does the UE transmit a Status Report with no NACK_SN and ACK_SN = 10? |
–> |
STATUS PDU |
3 |
P |
7A |
In the subframe following the one scheduled in step 6A the SS assigns 7 UL grants (UL grant allocation type 2) with a time spacing of 10 ms of size 840 bits. (Note 1, Note 6) |
<– |
(UL grant, 840 bits) |
– |
– |
7B |
The UE transmits RLC SDU#4. |
–> |
(RLC SDU#4) |
– |
– |
7C |
The UE transmits RLC SDU#5. |
–> |
(RLC SDU#5) |
– |
– |
7D |
The UE transmits RLC SDU#6. |
–> |
(RLC SDU#6) |
– |
– |
7E |
The UE transmits RLC SDU#7. |
–> |
(RLC SDU#7) |
– |
– |
7F |
The UE transmits RLC SDU#8. |
–> |
(RLC SDU#8) |
– |
– |
7G |
The UE transmits RLC SDU#9. |
–> |
(RLC SDU#9) |
– |
– |
7H |
The UE transmits RLC SDU#10. |
–> |
(RLC SDU#10) |
– |
– |
7I |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
8 |
Void |
– |
– |
– |
– |
9 |
After 300 ms the SS transmits an AMD PDU with SN=10 and P=0, and an AMD PDU with SN=12 and P=1. |
<– |
AMD PDU (SN=10, P=0) AMD PDU (SN=12, P=1) |
– |
– |
9A |
Check: Does the UE transmit a scheduling request within t-Reordering / 2 ms? |
–> |
(SR) |
4 |
F |
10 |
Within t-Reordering / 2 ms after the transmission of the first AMD PDU of Step 9, the SS transmits an AMD PDU with SN=11 and P=0. Note: AMD PDUs with SN 10,11 and 12 carry RLC SDU #11. |
<– |
AMD PDU (SN=11, P=0) |
– |
– |
10A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns 1 UL grant (UL grant allocation type 3) of size 40 bits. (Note 2) |
<– |
(UL grants, 40 bits) |
– |
– |
11 |
Check: Does the UE transmit a Status Report with no NACK_SN and ACK_SN=13? |
–> |
STATUS PDU |
4 |
P |
11A |
The SS assigns 1 UL grant (UL grant allocation type 3) of size 840 bits. (Note 1) |
<– |
(UL grant, 840 bits) |
– |
– |
11B |
The UE transmit RLC SDU#11. |
–> |
(RLC SDU#11) |
– |
– |
11C |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
12 |
Void |
– |
– |
– |
– |
13 |
Void |
– |
– |
– |
– |
14 |
After 300 ms the SS transmits an AMD PDU with SN=13 and P=0, and an AMD PDU with SN=19 and P=1. |
<– |
AMD PDU (SN=13, P=0) AMD PDU (SN=19, P=1) |
– |
– |
15 |
The SS waits for t-Reordering ms to ensure expiry. |
– |
– |
– |
– |
16 |
Void |
– |
– |
– |
– |
17 |
60 ms after step 15 the SS assigns an UL grant (UL grant allocation type 3) of size 72 bits. (Note 3) |
<– |
(UL Grant) |
– |
– |
18 |
Void |
– |
– |
– |
– |
– |
Steps 18a1 and 18b1 depends on the UE behaviour; the "lower case letter" identifies a step sequence that takes place if a specific behaviour happens |
– |
– |
– |
– |
18a1 |
Check: Does the UE transmit a Status Report with ACK_SN=16 and 2 NACK_SNs: 14 and 15? |
–> |
STATUS PDU |
5 |
P |
18b1 |
Check: Does the UE transmit a Status Report with ACK_SN=18 and 4 NACK_SNs: 14,15, 16 and 17? |
–> |
STATUS PDU |
5 |
P |
19 |
Void |
– |
– |
– |
– |
20 |
Void |
– |
– |
– |
– |
21 |
After 300 ms The SS transmits an AMD PDU with SN=14 and P=1. |
<– |
AMD PDU (SN=14, P=1) |
– |
– |
22 |
60 ms after step 21 the SS assigns an UL grant (UL grant allocation type 3) of size 72 bits. (Note 4) |
<– |
(UL Grant) |
– |
– |
23 |
Check: Does the UE transmit a Status Report with ACK_SN=20 and 4 NACK_SNs: 15, 16, 17 and 18? |
–> |
STATUS PDU |
5 |
P |
24 |
40 ms after step 22 the SS transmits 4 AMD PDU with SN=15, 16, 17, 18. Note: AMD PDUs with SN 13 to 19 carry RLC SDU #12. |
<– |
AMD PDU (SN=15, P=0) AMD PDU (SN=16, P=0) AMD PDU (SN=17, P=0) AMD PDU (SN=18, P=0) |
– |
– |
24A |
30 ms after the transmission of the last AMD PDU the SS assigns 1 UL grant (UL grant allocation type 3) of size 840 bits. (Note 1) |
<– |
(UL grant, 840 bits) |
– |
– |
25 |
The UE loopbacks the complete RLC SDU. |
–> |
(RLC SDU#12) |
– |
– |
26 |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
Note 1: UL grant of 840 bits (ITBS=14, NPRB=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit one PDU at a time. Note 2: UL grant of 40 bits (ITBS=3, NPRB=1, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit a Status Report with ACK_SN and (8-bit short BSR + 2x 8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding). Note 3: UL grant of 72 bits (ITBS=2, NPRB=2, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit (a Status Report with ACK_SN and 2 NACK_SNs (3x 8-bit MAC PDU subheader +8-bit Short BSR + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 2 x (12-bit NACK_SN/E1/E2) + 1-bit Padding) ) or (a Status Report with ACK_SN and 4 NACK_SNs (8-bit MAC PDU subheader +4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 4 x (12-bit NACK_SN/E1/E2) +1-bit padding)). Note 4: UL grant of 72 bits (ITBS=2, NPRB=2, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit a Status Report with ACK_SN and 4 NACK_SNs (8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 4 x (12-bit NACK_SN/E1/E2) +1-bit padding). Note 5: The first AMD PDU is transmitted in subframe #4. This subframe is as well suitable for the transmission of UL grants in TDD. Note 6: The SS transmits UL grant to the UE at every 10 ms to provide the necessary time division of the UE DL receptions and UL transmissions for UE operating in FDD type B half-duplex mode. See TS 36.523-3 sub-clause 7.26 for scheduling pattern for type B half-duplex FDD UE. |
7.2.3.10.3.3 Specific message contents
None.
7.2.3.11 Void
7.2.3.12 Void
7.2.3.13 AM RLC / Reconfiguration of RLC parameters by upper layers
7.2.3.13.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { t-PollRetransmit value is changed during reconfiguration of RLC parameters by upper layers }
then { UE starts using new t-PollRetransmit value }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { t-Reordering value is changed during reconfiguration of RLC parameters by upper layers }
then { UE starts using new t-Reordering value }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state and using AM RLC }
ensure that {
when { t-StatusProhibit value is changed during reconfiguration of RLC parameters by upper layers}
then { UE starts using new t-StatusProhibit value }
}
7.2.3.13.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.2, 5.2.2.1, 5.2.2.2, 5.2.2.3 and 5.2.3.
[TS 36.322, clause 5.2.2]
An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity.
[TS 36.322, clause 5.2.2.1]
Upon assembly of a new AMD PDU, the transmitting side of an AM RLC entity shall:
– increment PDU_WITHOUT_POLL by one;
– increment BYTE_WITHOUT_POLL by every new byte of Data field element that it maps to the Data field of the RLC data PDU;
– if PDU_WITHOUT_POLL >= pollPDU; or
– if BYTE_WITHOUT_POLL >= pollByte;
– include a poll in the RLC data PDU as described below.
Upon assembly of a AMD PDU or AMD PDU segment, the transmitting side of an AM RLC entity shall:
– if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data PDU awaiting for acknowledgements) after the transmission of the RLC data PDU; or
– if no new RLC data PDU can be transmitted after the transmission of the RLC data PDU (e.g. due to window stalling);
– include a poll in the RLC data PDU as described below.
To include a poll in a RLC data PDU, the transmitting side of an AM RLC entity shall:
– set the P field of the RLC data PDU to "1";
– set PDU_WITHOUT_POLL to 0;
– set BYTE_WITHOUT_POLL to 0;
After delivering a RLC data PDU including a poll to lower layer and after incrementing of VT(S) if necessary, the transmitting side of an AM RLC entity shall:
– set POLL_SN to VT(S) – 1;
– if t-PollRetransmit is not running:
– start t-PollRetransmit;
– else:
– restart t-PollRetransmit;
[TS 36.322, clause 5.2.2.2]
Upon reception of a STATUS report from the receiving RLC AM entity the transmitting side of an AM RLC entity shall:
– if the STATUS report comprises a positive or negative acknowledgement for the RLC data PDU with sequence number equal to POLL_SN:
– if the t-PollRetransmit is running:
– stop and reset t-PollRetransmit.
[TS 36.322, clause 5.2.2.3]
Upon expiry of t-PollRetransmit, the transmitting side of an AM RLC entity shall:
– if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC data PDU awaiting for acknowledgements); or
– if no new RLC data PDU can be transmitted (e.g. due to window stalling):
– consider the AMD PDU with SN = VT(S) – 1 for retransmission; or
– consider any AMD PDU which has not been positively acknowledged for retransmission;
– include a poll in a RLC data PDU as described in section 5.2.2.1.
[TS 36.322, clause 5.2.3]
An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative acknowledgements of RLC PDUs (or portions of them).
RRC configures whether or not the status prohibit function is to be used for an AM RLC entity.
Triggers to initiate STATUS reporting include:
– Polling from its peer AM RLC entity:
– When a RLC data PDU with SN = x and the P field set to “1” is received from lower layer, the receiving side of an AM RLC entity shall:
– if the PDU is to be discarded as specified in subclause 5.1.3.2.2; or
– if x < VR(MS) or x >= VR(MR):
– trigger a STATUS report;
– else:
– delay triggering the STATUS report until x < VR(MS) or x >= VR(MR).
NOTE: This ensures that the RLC Status report is transmitted after HARQ reordering.
– Detection of reception failure of an RLC data PDU:
– The receiving side of an AM RLC entity shall trigger a STATUS report when t-Reordering expires.
NOTE: The expiry of T_reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after VR(MS) is updated.
When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall:
– if t-StatusProhibit is not running:
– at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to lower layer;
– else:
– at the first transmission opportunity indicated by lower layer after t-StatusProhibit expires, construct a single STATUS PDU even if status reporting was triggered several times while T_status_prohibit was running and deliver it to lower layer;
When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall:
– start t-StatusProhibit.
When constructing a STATUS PDU, the AM RLC entity shall:
– for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in increasing SN order of PDUs and increasing byte segment order within PDUs, starting with SN = VR(R) up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU(s) indicated by lower layer:
– for an AMD PDU for which no byte segments have been received yet :
– include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU;
– for a continuous sequence of byte segments of a partly received AMD PDU that have not been received yet
– include in the STATUS PDU a set of NACK_SN, SOstart and SOend
– set the ACK_SN to the SN of the next not received RLC Data PDU which is not indicated as missing in the resulting STATUS PDU.
7.2.3.13.3 Test description
7.2.3.13.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.13.3.1-1.
Table 7.2.3.13.3.1-1: RLC settings
Parameter |
Value |
t-Reordering |
ms150 |
t-StatusProhibit |
ms300 |
t-PollRetransmit |
ms400 |
pollPDU |
pInfinity |
pollByte |
kBinfinity |
Table 7.2.3.13.3.1-1A: MAC settings
Parameter |
Value |
Condition |
sr-ConfigIndex-r13 |
10 |
FDD |
7 |
TDD |
|
dsr-TransMax-13 |
n16 |
7.2.3.13.3.2 Test procedure sequence
Table 7.2.3.13.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
1 |
Void |
– |
– |
– |
– |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
|
2 |
The SS transmits 4 AMD PDUs with P=0 and SN=0, 1, 2 and 4. The SS record time TA when AMD PDU#5 (with SN=4) is sent. |
<– |
AMD PDU#1 (SN=0, P=0) AMD PDU#2 (SN=1, P=0) AMD PDU#3 (SN=2, P=0) AMD PDU#5 (SN=4, P=0) |
– |
– |
2A |
The SS waits for 60 ms after the transmission of the first AMD PDU to ensure UE RLC has all the required SDUs available and then assigns 3 UL grants of size 840 bits (UL Grant Allocation type 2) with a time spacing of 10 ms. (Note 2, Note 5, Note 6) |
<– |
(UL grants, 840 bits) |
– |
– |
2B |
The UE transmits RLC SDU#1. |
–> |
(RLC SDU#1) |
– |
– |
2C |
The UE transmits RLC SDU#2. |
–> |
(RLC SDU#2) |
– |
– |
2D |
The UE transmits RLC SDU#3. |
–> |
(RLC SDU#3) |
– |
– |
2E |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
2F |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
3 |
Check 1: Does the UE transmit a STATUS PDU with NACK_SN=3 and ACK_SN=5? Record time TB. Check 2: Is (TB – TA ) = t-Reordering? |
–> |
STATUS PDU |
– |
– |
4 |
100 ms after the Status Report received at Step 3, he SS sends 4 AMD PDUs with P=0 and SN=5, 6, 8 and 9. |
<– |
AMD PDU#6 (SN=5, P=0) AMD PDU#7 (SN=6, P=0) AMD PDU#9 (SN=8, P=0) AMD PDU#10 (SN=9, P=0) |
– |
– |
4A |
Check 1: Does the UE transmit a Status Report with NACK_SN=3, ACK_SN=7? Record time TC Check 2: (TC – TB) = t-StatusProhibit? |
–> |
STATUS PDU |
– |
– |
5 |
The UE transmits a STATUS PDU with NACK_SN=3, NACK_SN=7 and ACK_SN=10. |
–> |
STATUS PDU |
– |
– |
6 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
7 |
After 300 ms the SS transmits 3 AMD PDUs with SN=3, 7 and 9. The SS sets the P field of all the AMD PDUs to 0 except for that of the AMD PDU with SN=9. |
<– |
AMD PDU#4 (SN=3, P=0) AMD PDU#8 (SN=7, P=0) AMD PDU#10 (SN=9, P=1) |
– |
– |
7A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns 1 UL grant of size 40 bits (UL Grant Allocation type 3). (Note 3) |
<– |
(UL grant, 40 bits) |
– |
– |
8 |
The UE transmits a Status Report with no NACK_SN and ACK_SN = 10. |
–> |
STATUS PDU |
– |
– |
8A |
In the subframe following the one scheduled in step 7A the SS assigns 7 UL grants of size 840 bits (UL Grant Allocation type 2) with a time spacing of 10 ms. (Note 2, Note 6) |
<– |
(UL grants, 840 bits) |
– |
– |
8B |
The UE transmits RLC SDU#4. |
–> |
(RLC SDU#4) |
– |
– |
8C |
The UE transmits RLC SDU#5. |
–> |
(RLC SDU#5) |
– |
– |
8D |
The UE transmits RLC SDU#6. |
–> |
(RLC SDU#6) |
– |
– |
8E |
The UE transmits RLC SDU#7. |
–> |
(RLC SDU#7) |
– |
– |
8F |
The UE transmits RLC SDU#8. |
–> |
(RLC SDU#8) |
– |
– |
8G |
The UE transmits RLC SDU#9. |
–> |
(RLC SDU#9) |
– |
– |
8H |
The UE transmits RLC SDU#10. |
–> |
(RLC SDU#10) |
– |
– |
8I |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
9 |
The SS transmits an AMD PDU to the UE. |
<– |
AMD PDU#11 (SN=10, P=0) |
– |
– |
9A |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
10 |
The UE transmits an AMD PDU with the same data as received in the corresponding DL AMD PDU. Record time TD. |
–> |
AMD PDU#11 (SN=10, P=1) |
– |
– |
11 |
Check 1: Does the UE set the poll bit as both the transmission and retransmission buffers become empty? Record time TE. |
–> |
AMD PDU#11 (SN=10, P=1) |
1 |
P |
11A |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
12 |
The SS reconfigures RLC in the UE and sets: – t-Reordering to ms200, – t-StatusProhibit to ms400, – t-PollRetransmit to ms500. (Note 1) |
– |
– |
– |
– |
– |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
13 |
The SS transmits 4 AMD PDUs with P=0 and SN=11, 12, 13 and 15. The SS record time TF when AMD PDU#16 (with SN=15) is sent. |
<– |
AMD PDU#12 (SN=11, P=0) AMD PDU#13 (SN=12, P=0) AMD PDU#14 (SN=13, P=0) AMD PDU#16 (SN=15, P=0) |
– |
– |
13A |
The SS waits for 60 ms after the transmission of the first AMD PDU to ensure UE RLC has all the required SDUs available and then assigns 3 UL grants of size 840 bits (UL Grant Allocation type 2) with a time spacing of 10 ms. (Note 2, Note 5, Note 6) |
<– |
(UL grants, 840 bits) |
– |
– |
13B |
The UE transmits RLC SDU#12. |
–> |
(RLC SDU#12) |
– |
– |
13C |
The UE transmits RLC SDU#13. |
–> |
(RLC SDU#13) |
– |
– |
13D |
The UE transmits RLC SDU#14. |
–> |
(RLC SDU#14) |
– |
– |
13E |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
13F |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
14 |
Check 1: Does the UE transmit a STATUS PDU with NACK_SN=14 and ACK_SN=16? Record time TG. Check 2: Is (TG – TF ) = updated value of t-Reordering? |
–> |
STATUS PDU |
2 |
P |
15 |
100 ms after the Status Report received at Step 14, t he SS sends 4 AMD PDUs with P=0 and SN=16, 17, 19 and 20. |
<– |
AMD PDU#17 (SN=16, P=0) AMD PDU#18 (SN=17, P=0) AMD PDU#20 (SN=19, P=0) AMD PDU#21 (SN=20, P=0) |
– |
– |
15A |
Check 1: Does the UE transmit a STATUS PDU with NACK_SN=14 and ACK_SN=18? Record time TH. Check 2: Is (TH – TG ) = updated value of t-StatusProhibit? |
–> |
STATUS PDU |
3 |
P |
16 |
The UE transmits a STATUS PDU with NACK_SN=14, NACK_SN=18 and ACK_SN=21. |
–> |
STATUS PDU |
– |
– |
17 |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
18 |
After 450 ms the SS transmits 3 AMD PDUs with SN=14, 18 and 20. The SS sets the P field of all the AMD PDUs to 0 except for that of the AMD PDU with SN=20. |
<– |
AMD PDU#15 (SN=14, P=0) AMD PDU#19 (SN=18, P=0) AMD PDU#21 (SN=20, P=1) |
– |
– |
18A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns 1 UL grant of size 40 bits (UL Grant Allocation type 3). (Note 3) |
<– |
(UL grant, 40 bits) |
– |
– |
19 |
The UE transmits a Status Report with no NACK_SN and ACK_SN = 21. |
–> |
STATUS PDU |
– |
– |
19A |
In the subframe following the one scheduled in step 18A the SS assigns 7 UL grants of size 840 bits (UL Grant Allocation type 2) with a time spacing of 10 ms. (Note 2, Note 6) |
<– |
(UL grants, 840 bits) |
– |
– |
19B |
The UE transmits RLC SDU#15. |
–> |
(RLC SDU#15) |
– |
– |
19C |
The UE transmits RLC SDU#16. |
–> |
(RLC SDU#16) |
– |
– |
19D |
The UE transmits RLC SDU#17. |
–> |
(RLC SDU#17) |
– |
– |
19E |
The UE transmits RLC SDU#18. |
–> |
(RLC SDU#18) |
– |
– |
19F |
The UE transmits RLC SDU#19. |
–> |
(RLC SDU#19) |
– |
– |
19G |
The UE transmits RLC SDU#20. |
–> |
(RLC SDU#20) |
– |
– |
19H |
The UE transmits RLC SDU#21. |
–> |
(RLC SDU#21) |
– |
– |
19I |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
20 |
The SS transmits an AMD PDU to the UE. |
<– |
AMD PDU#22 (SN=21, P=0) |
– |
– |
20A |
The SS starts the UL default grant transmission |
– |
– |
– |
– |
21 |
The UE transmits an AMD PDU with the same data as received in the corresponding DL AMD PDU. Record time TI. |
–> |
AMD PDU#22 (SN=21, P=1) |
– |
– |
22 |
Check 1: Does the UE set the poll bit as both the transmission and retransmission buffers become empty? Record time TJ. |
–> |
AMD PDU#22 (SN=21, P=1) |
1 |
P |
23 |
The SS transmits a STATUS PDU |
<– |
STATUS PDU |
– |
– |
Note 1: The RRC Connection Reconfiguration procedure is performed. Note 2: UL grant of 840 bits (ITBS=14, NPRB=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit one PDU at a time. Note 3: UL grant of 40 bits (ITBS=3, NPRB=1, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit a Status Report with ACK_SN and (16-bit short BSR + 8-bit MAC PDU subheader + 4-bit D/C/CPT + 10-bit ACK_SN + 1-bit E1 + 1bit padding). Note 4: Every DL AMD PDU contains 1 RLC SDU size of 100 bytes. Note 5: The first AMD PDU is transmitted in subframe #4. This subframe is as well suitable for the transmission of UL grants in TDD. Note 6: The SS transmits UL grant to the UE at every 10 ms to provide the necessary time division of the UE DL receptions and UL transmissions for UE operating in FDD type B half-duplex mode. See TS 36.523-3 sub-clause 7.26 for scheduling pattern for type B half-duplex FDD UE. |
7.2.3.13.3.3 Specific message contents
None.
7.2.3.14 AM RLC / In sequence delivery of upper layers PDUs
7.2.3.14.1 Test Purpose (TP)
(1)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives duplicate AMD PDUs }
then { UE discards the duplicate AMD PDUs }
}
(2)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives an AMD PDU with a SN gap }
then { UE sends STATUS PDU to request retransmissions of PDUs in the SN gap}
}
(3)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives PDUs within a SN gap }
then { RLC reassembles and reorders the AMD PDUs and deliver them to the upper layer in sequence }
}
7.2.3.14.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 4.2.1.3.3.
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
– detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;
– reorder the RLC data PDUs if they are received out of sequence;
– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;
– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
…
7.2.3.14.3 Test description
7.2.3.14.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18].
7.2.3.14.3.2 Test procedure sequence
Table 7.2.3.14.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits an AMD PDU to the UE. This PDU carries SDU#1. |
<– |
AMD PDU#1 (SN=0) |
||
2 |
The SS transmits an AMD PDU to the UE. This PDU carries SDU#1. |
<– |
AMD PDU#1 (SN=0) |
– |
– |
3 |
Check: Does the UE transmit RLC SDU#1? (Note) |
–> |
(RLC SDU#1) |
1 |
P |
3A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
4 |
The SS transmits an AMD PDU to the UE. This PDU contains SDU#2, and the 1st part of SDU#3. |
<– |
AMD PDU#2 (SN=1) |
– |
– |
5 |
Check: Does the UE transmit RLC SDU#2? |
–> |
(RLC SDU#2) |
1 |
P |
5A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
6 |
The SS transmits an AMD PDU to the UE. This PDU contains SDU#2, and the 1st part of SDU#3. |
<– |
AMD PDU#2 (SN=1) |
– |
– |
7 |
Check: Does the UE transmit RLC SDU#2? |
–> |
(RLC SDU#2) |
1 |
F |
8 |
The SS transmits an AMD PDU to the UE. This PDU contains the 2nd part of SDU#3. |
<– |
AMD PDU#3 (SN=2) |
– |
– |
9 |
Check: Does the UE transmit RLC SDU#3? |
–> |
(RLC SDU#3) |
1 |
P |
9A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=3) |
– |
– |
10 |
The SS transmits an AMD PDU to the UE. This PDU contains the last part of SDU#6. |
<– |
AMD PDU#6 (SN=5) |
– |
– |
11 |
The SS transmits an AMD PDU to the UE. This PDU contains the 2nd part of SDU#5, and the 1st part of SDU#6. |
<– |
AMD PDU#5 (SN=4) |
– |
– |
11A |
The SS does not allocate any uplink grant. |
– |
– |
– |
– |
12 |
The SS transmits an AMD PDU to the UE. This PDU carries SDU#4 and the 1st part of SDU#5. |
<– |
AMD PDU#4 (SN=3) |
– |
– |
12A |
The SS waits for 60 ms then assigns an UL grant sufficient for the UE to loopback SDU#4, SDU#5 and SDU#6. |
<– |
(UL grant) |
– |
– |
13 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#4, RLC SDU#5 and RLC SDU#6 in its data field? |
–> |
AMD PDU (RLC SDU#4, RLC SDU#5, RLC SDU#6) |
3 |
P |
14 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=4) |
– |
– |
15 |
Void |
– |
– |
– |
– |
16 |
The SS transmits an AMD RLC PDU to the UE. This PDU contains the last part of SDU#9. |
<– |
AMD PDU#9 (SN=8, P=1) |
– |
– |
17 |
Check: Does the UE transmit a STATUS PDU NACK_SN/E1/E2 fields set correctly to inform SS of missing PDUs #7, #8, (ACK_SN =9, NACK_SN = 6, NACK_SN = 7)? |
–> |
STATUS PDU |
2 |
P |
18 |
The SS transmits an AMD PDU to the UE. This PDU contains SDU#8, and the 1st part of SDU#9. |
<– |
AMD PDU#8 (SN=7) |
– |
– |
18A |
The SS does not allocate any uplink grant. |
– |
– |
– |
– |
19 |
The SS transmits an AMD PDU to the UE. This PDU carries SDU#7. |
<– |
AMD PDU#7 (SN=6) |
– |
– |
19A |
The SS waits for 60 ms then assigns an UL grant sufficient for the UE to loopback SDU#7, SDU#8 and SDU#9. |
<– |
(UL grants) |
– |
– |
20 |
Check: Does the UE transmit an AMD PDU containing RLC SDU#7, RLC SDU#8 and RLC SDU#9 in its data field? |
–> |
AMD PDU (RLC SDU#7, RLC SDU#8, RLC SDU#9) |
3 |
P |
21 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=5) |
– |
– |
22 |
Void |
– |
– |
– |
– |
Note: UE may transmit RLC SDU #1 between Step 1 and Step 2. |
7.2.3.14.3.3 Specific message contents
None.
7.2.3.15 AM RLC / Re-ordering of RLC PDU segments
7.2.3.15.1 Test Purpose (TP)
(1)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives RLC AM PDU segments }
then { UE reorders RLC AMD PDU segments received out of sequence }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { t-Reordering expires }
then { Set VR(MS) to SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been received }
}
7.2.3.15.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 4.2.1.3.3, 5.1.3.2.1, 5.1.3.2.2, 5.1.2.3.3 and 5.1.2.3.4.
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
…
– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;
– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
…
[TS 36.322, clause 5.1.3.2.1]
The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and VR(MR) as follows:
– a SN falls within the receiving window if VR(R) <= SN < VR(MR);
– a SN falls outside of the receiving window otherwise.
When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall:
– either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1.3.2.2);
– if the received RLC data PDU was placed in the reception buffer:
– update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop t–Reordering as needed (see sub clause 5.1.3.2.3).
When t-Reordering expires, the receiving side of an AM RLC entity shall:
– update state variables and start t-Reordering as needed (see sub clause 5.1.3.2.4).
[TS 36.322, clause 5.1.3.2.2]
When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of an AMD PDU with SN = x, the receiving side of an AM RLC entity shall:
– if x falls outside of the receiving window; or
– if byte segment numbers y to z of the AMD PDU with SN = x have been received before:
– discard the received RLC data PDU;
– else:
– place the received RLC data PDU in the reception buffer;
– if some byte segments of the AMD PDU contained in the RLC data PDU have been received before:
– discard the duplicate byte segments.
[TS 36.322, clause 5.1.3.2.3]
When a RLC data PDU with SN = x is placed in the reception buffer, the receiving side of an AM RLC entity shall:
– if all byte segments of the AMD PDU with SN = VR(MS) are received:
– update VR(MS) to the SN of the first AMD PDU with SN > current VR(MS) for which not all byte segments have been received;
– if x = VR(R):
– if all byte segments of the AMD PDU with SN = VR(R) are received:
– update VR(R) to the SN of the first AMD PDU with SN > current VR(R) for which not all byte segments have been received;
– update VR(MR) to the updated VR(R) + AM_Window_Size;
– reassemble RLC SDUs from any byte segments of AMD PDUs with SN that falls outside of the receiving window and in-sequence byte segments of the AMD PDU with SN = VR(R), remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before;
– if x >= VR(H)
– update VR(H) to x+ 1;
– if t-Reordering is running:
– if VR(X) = VR(R); or
– if VR(X) falls outside of the receiving window and VR(X) is not equal to VR(MR):
– stop and reset t-Reordering;
– if t-Reordering is not running (includes the case t-Reordering is stopped due to actions above):
– if VR (H) > VR(R):
– start t-Reordering;
– set VR(X) to VR(H).
[TS 36.322, clause 5.1.3.2.4]
When t-Reordering expires, the receiving side of an AM RLC entity shall:
– update VR(MS) to the SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been received;
– if VR(H) > VR(MS):
– start t-Reordering;
– set VR(X) to VR(H).
7.2.3.15.3 Test description
7.2.3.15.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 98 bytes.
7.2.3.15.3.2 Test procedure sequence
Table 7.2.3.15.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
1 |
The SS transmits one AMD PDU containing SDU#8 (100 bytes) in its data field to the UE. SN=7 indicates the loss of 7 PDUs. |
<– |
AMD PDU#8 (SN=7) |
– |
– |
2 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#1 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#1, which contained SDU#1 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#1 (SN=0) segment 1 |
– |
– |
3 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#2 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#2, which contained SDU#2 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#2 (SN=1) segment 2 |
– |
– |
4 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#3 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#3, which contained SDU#3 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#3 (SN=2) segment 1 |
– |
– |
5 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#4 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#4, which contained SDU#4 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#4 (SN=3) segment 2 |
– |
– |
6 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#4 in its data field to the UE. This AMD PDU segment carries part 1of AMD PDU#4, which contained SDU#4 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#4 (SN=3) segment 1 |
– |
– |
7 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#1 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#1, which contained SDU#1 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#1 (SN=0) segment 2 |
– |
– |
8 |
Void |
||||
9 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#2 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#2, which contained SDU#2 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#2 (SN=1) segment 1 |
– |
– |
10 |
Void |
||||
11 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#3 in its data field to the UE. This AMD PDU segment carries part 2 of PDU#3, which contained SDU#3 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#3 (SN=2) segment 2 |
– |
– |
11A |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#7 in its data field to the UE. This AMD PDU segment carries part 1 of PDU #7, which contained SDU#7 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#7 (SN=6) segment 1 |
– |
– |
11B |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#6 in its data field to the UE. This AMD PDU segment carries segment 2 of AMD PDU#6, which contained SDU#6 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#6 (SN=5) segment 2 |
– |
– |
11C |
The SS waits for 60 ms then SS transmits 4 uplink grants (UL grant allocation type 2) with a time spacing of 10 ms, each allowing the UE to transmit 1 RLC SDU. (Note 1) |
<– |
(UL grants) |
– |
– |
11D |
Check: Does the UE transmit an RLC SDU containing SDU#1 in its data field? |
–> |
(RLC SDU#1) |
1 |
P |
11E |
Check: Does the UE transmit an RLC SDU containing SDU#2 in its data field? |
–> |
(RLC SDU#2) |
1 |
P |
12 |
Check: Does the UE transmit an RLC SDU containing SDU#3 in its data field? |
–> |
(RLC SDU#3) |
1 |
P |
13 |
Check: Does the UE transmit an RLC SDU containing SDU#4 in its data field? |
–> |
(RLC SDU#4) |
1 |
P |
14 |
The SS transmits an RLC STATUS PDU to the UE. This PDU acks PDUs up to those including SDU#4. ACK_SN=4. |
<– |
STATUS PDU |
– |
– |
15 |
Void |
||||
16 |
Void |
||||
17 |
Wait for t-Reordering to run out at the UE side. |
– |
– |
– |
– |
18 |
Check: Does the UE transmit a Status Report with NACK_SN=4, NACK_SN=5 with SOStart=0 and SOEnd=49, and NACK_SN=6 with SOStart=50 and SOEnd=32767 (special SOEnd value), and ACK_SN=8? |
–> |
STATUS PDU |
2 |
P |
19 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#7 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#7, which contained SDU#7 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#7 (SN=6) segment 2 |
– |
– |
20 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#6 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#6, which contained SDU#6 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#6 (SN=5) segment 1 |
– |
– |
21 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#5 in its data field to the UE. This AMD PDU segment carries part 1 of AMD PDU#5, which contained SDU#5 (100 bytes) in its data field. SO=0 and LSF=0. |
<– |
AMD PDU#5 (SN=4) segment 1 |
– |
– |
22 |
Wait for t-Reordering to run out at the UE side. |
– |
– |
– |
– |
23 |
Check: Does the UE transmit a Status Report with NACK_SN=4 with SOStart=50 and SOEnd=32767 (special SOEnd value), and ACK_SN=8? |
–> |
STATUS PDU |
2 |
P |
24 |
The SS transmits one AMD PDU segment containing 50 bytes of SDU#5 in its data field to the UE. This AMD PDU segment carries part 2 of AMD PDU#5, which contained SDU#5 (100 bytes) in its data field. SO=50 and LSF=1. |
<– |
AMD PDU#5 (SN=4) segment 2 |
– |
– |
24A |
The SS waits for 60 ms then SS transmits 4 uplink grants (UL grant allocation type 2) with a time spacing of 10 ms, each allowing the UE to transmit 1 RLC SDU. (Note 1) |
<– |
(UL grants) |
– |
– |
25 |
Check: Does the UE transmit an RLC SDU containing SDU#5 in its data field? |
–> |
(RLC SDU#5) |
1 |
P |
26 |
Check: Does the UE transmit an RLC SDU containing SDU#6 in its data field? |
–> |
(RLC SDU#6) |
1 |
P |
27 |
Check: Does the UE transmit an RLC SDU containing SDU#7 in its data field? |
–> |
(RLC SDU#7) |
1 |
P |
28 |
Check: Does the UE transmit an RLC SDU containing SDU#8 in its data field? |
–> |
(RLC SDU#8) |
1 |
P |
29 |
The SS transmits an RLC STATUS PDU to the UE. This PDU acks PDUs up to those including SDU#7. ACK_SN=8. |
<– |
STATUS PDU |
– |
– |
Note 1: The SS transmits UL grant to the UE at every 10 ms to provide the necessary time division of the UE DL receptions and UL transmissions for UE operating in FDD type B half-duplex mode. See TS 36.523-3 sub-clause 7.26 for scheduling pattern for type B half-duplex FDD UE. |
7.2.3.15.3.3 Specific message contents
Table 7.2.3.15.3.3-1: RLC-Config-DRB-AM(preamble, Table 7.2.3.15.3.2-1)
Derivation path: 36.508 clause 4.8.2.1.3.2, Table 4.8.2.1.3.2-1 |
|||
Information Element |
Value/Remark |
Comment |
Condition |
RLC-Config-DRB-AM ::= CHOICE { |
|||
am SEQUENCE { |
|||
dl-AM-RLC SEQUENCE { |
|||
t-Reordering |
ms100 |
||
} |
|||
} |
|||
} |
7.2.3.16 AM RLC / Re-transmission of RLC PDU without re-segmentation
7.2.3.16.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives a STATUS PDU including a NACK_SN for missing AMD PDUs and missing AMD PDUs can fit into within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity}
then { UE successfully retransmits missing AMD PDUs without re-segmentation}
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { NACK received for missing AMD PDUs and RETX_COUNT < maxRetxThreshold }
then { UE retransmits AMD PDUs }
}
(3)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { an AMD PDU or a portion of an AMD PDU is considered for retransmission and if RETX_COUNT = maxRetxThreshold }
then { UE indicates to upper layers that max retransmission has been reached }
}
7.2.3.16.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.1.
[TS 36.322 clause 5.2.1]
The transmitting side of an AM RLC entity can receive a negative acknowledgement (notification of reception failure by its peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by the following:
– STATUS PDU from its peer AM RLC entity.
When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by a STATUS PDU from its peer AM RLC entity, the transmitting side of the AM RLC entity shall:
– if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S):
– consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was received for retransmission.
When an AMD PDU or a portion of an AMD PDU is considered for retransmission, the transmitting side of the AM RLC entity shall:
– if the AMD PDU is considered for retransmission for the first time:
– set the RETX_COUNT associated with the AMD PDU to zero;
– else, if it (the AMD PDU or the portion of the AMD PDU that is considered for retransmission) or a portion of it is not pending for retransmission already:
– increment the RETX_COUNT;
– if RETX_COUNT = maxRetxThreshold:
– indicate to upper layers that max retransmission has been reached.
When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall:
– if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity:
– deliver the AMD PDU as it is except for the P field (the P field should be set according to sub clause 5.2.2) to lower layer;
– otherwise:
– segment the AMD PDU form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.
When retransmitting a portion of an AMD PDU, the transmitting side of an AM RLC entity shall:
– segment the portion of the AMD PDU as necessary, form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.
When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall:
– only map the Data field of the original AMD PDU to the Data field of the new AMD PDU segment;
– set the header of the new AMD PDU segment in accordance with the description in sub clause 6.;
– set the P field according to sub clause 5.2.2.
7.2.3.16.3 Test description
7.2.3.16.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with a loopback size of 98 bytes with the exceptions listed in table 7.2.3.16.3.1-1.
Table 7.2.3.16.3.1-1: PDCP-Config-DRB-AM
Information Element |
Value/remark |
Comment |
Condition |
PDCP-Config-DRB-AM ::= SEQUENCE { |
|||
rlc-AM SEQUENCE { |
|||
statusReportRequired |
FALSE |
||
} |
|||
} |
7.2.3.16.3.2 Test procedure sequence
Table 7.2.3.16.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
The SS transmits one AMD PDU containing SDU#1 (100 bytes) in its data field. |
<– |
AMD PDU#1 |
– |
– |
2 |
The UE transmits one AMD PDU containing SDU#1 in its data field. |
–> |
AMD PDU#1 (SN=0) |
– |
– |
3 |
The SS transmits one AMD PDU containing SDU#2 (100 bytes) in its data field. |
<– |
AMD PDU#2 |
– |
– |
4 |
The UE transmits one AMD PDU containing SDU#2 in its data field. |
–> |
AMD PDU#2 (SN=1) |
– |
– |
5 |
The SS transmits an RLC STATUS PDU. ACK_SN=2, NACK_SN=0. |
<– |
STATUS PDU |
– |
– |
6 |
Check: Does the UE transmit the AMD PDU not yet acknowledged? |
–> |
AMD PDU#1 (SN=0) |
1 |
P |
7 |
The SS transmits an RLC STATUS PDU. ACK_SN=2. |
<– |
STATUS PDU |
– |
– |
8 |
The SS transmits one AMD PDU containing SDU#3 (100 bytes) in its data field. |
<– |
AMD PDU#3 |
– |
– |
9 |
The UE transmits an AMD PDU containing SDU#3 in its data field. |
–> |
AMD PDU#3 (SN=2) |
– |
– |
– |
EXCEPTION: Step 10 to 11 shall be repeated maxRetxThreshold times |
– |
– |
– |
– |
10 |
The SS transmits an RLC STATUS PDU. ACK_SN =3 and NACK_SN =2. |
<– |
STATUS PDU |
– |
– |
11 |
Check: Does the UE retransmit the AMD PDU not yet acknowledged? |
–> |
AMD PDU#3 (SN=2) |
2 |
P |
12 |
The SS transmits an RLC STATUS PDU. ACK_SN =3 and NACK_SN =2. |
<– |
STATUS PDU |
– |
– |
13 |
Check: Does the UE transmit an RRC Connection Re-establishment Request message? Note 1 |
– |
3 |
P |
|
14 |
The SS transmits RRCConnectionReestablishment message. |
– |
– |
– |
– |
15 |
The UE transmits RRCConnectionReestablishmentComplete message. |
– |
– |
– |
– |
16 |
The SS transmits an RRCConnectionReconfiguration message to resume SRB2 and DRB1. |
– |
– |
– |
– |
– |
EXCEPTION: Step 17 and Step 18 can happen in any order. |
– |
– |
– |
– |
17 |
The UE transmits an RRCConnectionReconfigurationComplete message. |
– |
– |
– |
– |
18 |
The UE retransmits the AMD PDU not yet acknowledged. Note 2. |
–> |
AMD PDU#3 (SN=0) |
– |
– |
Note 1: The RRC Connection Re-establishment procedure is initiated. See 36.331 cl. 5.3.7.2 and 5.3.11.3. Note 2: The PDCP PDU contained in this AMD PDU carries PDCP SN=2. |
7.2.3.16.3.3 Specific message contents
Table 7.2.3.16.3.3-1: RRCConnectionReconfiguration (step 16, Table 7.2.3.16.3.2-1)
Derivation Path: 36.508, Table 4.6.1-8 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCConnectionReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
c1 CHOICE{ |
|||
rrcConnectionReconfiguration-r8 SEQUENCE { |
|||
radioResourceConfigDedicated |
RadioResourceConfigDedicated-HO |
||
} |
|||
} |
|||
} |
|||
} |
7.2.3.17 AM RLC / Re-segmentation RLC PDU / SO, FI, LSF
7.2.3.17.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { AMD PDU to be retransmitted does not fit in new allocated TBS }
then { UE segments AMD PDU into AMD PDU segments }
}
(2)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { AMD PDU segment to be retransmitted does not fit in new allocated TBS }
then { UE resegments AMD PDU segment to fit TBS }
}
7.2.3.17.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 4.2.1.3.2, 5.2.1, 6.2.1.4 and 6.2.1.5.
[TS 36.322, clause 4.2.1.3.2]
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall:
– segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer.
The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ):
– if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments;
– the number of re-segmentation is not limited.
When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall:
– include relevant RLC headers in the RLC data PDU.
[TS 36.322 clause 5.2.1]
…
When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall:
– if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity:
– deliver the AMD PDU as it is except for the P field (the P field should be set according to sub clause 5.2.2) to lower layer;
– otherwise:
– segment the AMD PDU form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.
When retransmitting a portion of an AMD PDU, the transmitting side of an AM RLC entity shall:
– segment the portion of the AMD PDU as necessary form a new AMD PDU segment which will fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity and deliver the new AMD PDU segment to lower layer.
When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall:
– only map the Data field of the original AMD PDU to the Data field of the new AMD PDU segment;
– set the header of the new AMD PDU segment in accordance with the description in sub clause 6.;
– set the P field according to sub clause 5.2.2.
[TS 36.322, clause 6.2.1.4]
AMD PDU consists of a Data field and an AMD PDU header.
AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).
An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI
….
[TS 36.322, clause 6.2.1.5]
AMD PDU segment consists of a Data field and an AMD PDU segment header.
AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s).
An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the last LI.
…
7.2.3.17.3 Test description
7.2.3.17.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 98 bytes and the exceptions listed in table 7.2.3.17.3.1-1 applicable for the configured AM DRB.
Table 7.2.3.17.3.1-1: RLC settings
Parameter |
Value |
t-PollRetransmit |
ms150 |
7.2.3.17.3.2 Test procedure sequence
Table 7.2.3.17.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
0 |
The SS stops the UL grant transmission. |
– |
– |
– |
– |
1 |
The SS transmits one AMD PDU containing SDU#1 (100 bytes) in its data field. |
<– |
AMD PDU#1 |
– |
– |
1A |
60 ms after step 1 the SS assigns one default grant (UL grant allocation type 2). (Note 6) |
<– |
(UL grant, 840 bits) |
– |
– |
2 |
The UE transmits an AMD PDU with the same data contents as received in the corresponding part of DL PDU#1? |
–> |
AMD PDU#1 (SN=0) |
– |
– |
3 |
20 ms after step 1 The SS transmits one AMD PDU containing SDU#2 (100 bytes) in its data field. |
<– |
AMD PDU#2 |
– |
– |
3A |
60 ms after step 3 the SS assigns one default grant (UL grant allocation type 2). (Note 6) |
<– |
(UL grant, 840 bits) |
– |
– |
4 |
The UE transmits an AMD PDU with the same data contents as received in the corresponding part of DL PDU#2? |
–> |
AMD PDU#2 (SN=1) |
– |
– |
5 |
Void |
– |
– |
– |
– |
6 |
The SS transmits a STATUS PDU. This PDU nacks the AMD PDU with SN=0. NACK_SN=0 and ACK_SN=2. |
<– |
STATUS PDU |
– |
– |
6A |
The SS waits for 20 ms and then allocates 2 UL grants (UL grant allocation type 2) of size 472 bits such that there is 20 ms gap between UL grants (Note 1, Note 4) |
<– |
(UL grants, 472 bits) |
– |
– |
7 |
Check: Does the UE transmit an AMD PDU segment with SO=0, LSF=0 and the same data contents at the received positions as in the original AMD PDU? |
–> |
AMD PDU#1 segment 1 (SN=0) |
1 |
P |
8 |
Check: Does the UE transmit an AMD PDU segment with SO=<x>, LSF=1 and the same data contents at the received positions as in the original AMD PDU? (Note 3) |
–> |
AMD PDU#1 segment 2 (SN=0) |
1 |
P |
9 |
Void |
– |
– |
– |
– |
10 |
After 100 ms the SS transmits a STATUS PDU. This PDU nacks the AMD PDU with SN=0. NACK_SN=0, SOStart=0, SOEnd=<x-1> and ACK_SN =2. (Note 3, Note 5) |
<– |
STATUS PDU |
– |
– |
10A |
The SS waits for 20 ms and then allocates 2 UL grants (UL grant allocation type 2) of size 328 bits such that there is 20 ms gap between UL grants (Note 2) (Note 4) |
<– |
(UL grants, 472 bits) |
– |
– |
11 |
Check: Does the UE transmit an AMD PDU segment with SO=0, LSF=0 and the same data contents at the received positions as in the original AMD PDU? |
–> |
AMD PDU#1 segment 1, 1st part (SN=0) |
2 |
P |
12 |
Check: Does the UE transmit an AMD PDU segment with SO=<y>, LSF=0 and the same data contents at the received positions as in the original AMD PDU? (Note 3) |
–> |
AMD PDU#1 segment 1, 2nd part (SN=0) |
2 |
P |
13 |
The SS transmits a STATUS PDU. This PDU acks the AMD PDUs with SN=0 and SN=1. ACK_SN=2. |
<– |
STATUS PDU |
– |
– |
Note 1: UL grant of 472 bits (ITBS=7, NPRB=4, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will segment into 2 AMD PDUs. MAC PDU of 472 bits=59 bytes fits an AMD PDU payload of >= 50 bytes + 2 bytes AMD PDU header + 2 bytes of segment header + ? bytes spare for MAC header and possible RLC STATUS PDU and BSR report. Note 2: UL grant of 328 bits (ITBS=5, NPRB=4, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will segment into 2 AMD PDUs. MAC PDU of 328 bits=41 bytes fits an AMD PDU payload of >= 25 bytes + 2 bytes AMD PDU header + 2 bytes of segment header + ? bytes spare for MAC header and possible RLC STATUS PDU and BSR report. Note 3: The values x and y depend upon the need of the UE to add RLC STATUS PDU and BSR report. The TBS has been chosen to ensure that the PDUs to be resegmented can be carried in 2 segments. Note 4: 20 ms gap between transmissions both in DL and UL respectively allows TTCN to tolerate one HARQ retransmission (FDD/TDD) per transport block, if such happen (TS 36.523-3). Note 5: As <x> becomes available in step 8 only the transmission in step 10 can only be scheduled afterwards. This requires a 100 ms activation time. Note 6: UL grant of 840 bits (ITBS=14, NPRB=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to transmit one PDU at a time. |
7.2.3.17.3.3 Specific message contents
None.
7.2.3.18 AM RLC / Reassembly / AMD PDU reassembly from AMD PDU segments, segmentation Offset and Last Segment Flag fields
7.2.3.18.1 Test Purpose (TP)
(1)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives AM PDU segments }
then { UE delivers reassembled RLC SDU to upper layer}
}
(2)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives RLC AM PDU segments without segment header extension part }
then { UE correctly reassembles RLC AMD PDU segments into RLC AMD PDUs }
}
(3)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives RLC AM PDU segments with segment header extension part }
then { UE correctly reassembles RLC AMD PDU segments into RLC AMD PDUs }
}
(4)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives duplicate RLC AM PDU segments }
then { UE discards duplicate RLC AMD PDU segments }
}
(5)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE receives RLC AM PDU segments out of sequence }
then { UE delivers reassembled RLC SDU to upper layer }
}
(6)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives RLC AMD PDU segments with segments lost }
then { UE transmits STATUS PDU to request retransmission of missing segments }
}
(7)
with { UE in E-UTRAN RRC_CONNECTED state }
ensure that {
when { UE receives overlapping RLC AMD PDU segments }
then { UE discards duplicate RLC AMD PDU byte segments }
}
7.2.3.18.2 Conformance requirements
References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 4.2.1.3.3, 5.1.3.2.2, 6.2.1.4 and 6.2.1.5.
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
– detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;
– reorder the RLC data PDUs if they are received out of sequence;
– detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity;
– reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence.
…
[TS 36.322, clause 5.1.3.2.2]
When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of an AMD PDU with SN = x, the receiving side of an AM RLC entity shall:
– if x falls outside of the receiving window; or
– if byte segment numbers y to z of the AMD PDU with SN = x have been received before:
– discard the received RLC data PDU;
– else:
– place the received RLC data PDU in the reception buffer;
– if some byte segments of the AMD PDU contained in the RLC data PDU have been received before:
– discard the duplicate byte segments.
[TS 36.322, clause 6.2.1.4]
AMD PDU consists of a Data field and an AMD PDU header.
AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and consists of E(s) and LI(s).
An AMD PDU header consists of an extension part only when more than one Data field elements are present in the AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI.
…
[TS 36.322, clause 6.2.1.5]
AMD PDU segment consists of a Data field and an AMD PDU segment header.
AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s).
An AMD PDU segment header consists of an extension part only when more than one Data field elements are present in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the last LI.
…
7.2.3.18.3 Test description
7.2.3.18.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 32 bytes.
7.2.3.18.3.2 Test procedure sequence
Table 7.2.3.18.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message/PDU/SDU |
||||
1 |
The SS transmits an AMD PDU containing the first half (17 bytes) of SDU#1 in its data field. This PDU is in error (SN falls outside of the receiving window) and is to be discarded by the UE. |
<– |
AMD PDU#1 (SN=WindowSize+3) |
– |
– |
2 |
The SS transmits an AMD PDU containing SDU#2 (34 bytes) in its data field with the P-bit set. |
<– |
AMD PDU#2 (SN=1, P=1) |
– |
– |
3 |
The UE transmits a STATUS PDU with NACK_SN field indicating missing PDU#1. ACK_SN=2, NACK_SN=0. |
–> |
STATUS PDU |
– |
– |
3A |
The SS stops the UL grant transmission. |
– |
– |
– |
– |
4 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#1 (AMD PDU#1 carries SDU#1) containing the first 17 bytes of SDU#1 in its data field. SO=0 and LSF=0. No header extension part is provided. |
<– |
AMD PDU#1 (SN=0) segment 1 |
– |
– |
5 |
The SS transmits an AMD PDU segment of AMD PDU#1 (AMD PDU#1 carries SDU#1) containing the last 17 bytes of SDU#1 in its data field with the P-bit set. SO=17 and LSF=1. No header extension part is provided. |
<– |
AMD PDU #1 (SN=0, P=1) segment 2 |
– |
– |
5A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns one default UL grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
6 |
Check: Does the UE transmit a STATUS PDU with ACK_SN=2, thus acknowledging the reception of PDUs with SN=0 and SN=1, and no NACK_SN provided? |
–> |
STATUS PDU |
2 |
P |
7 |
Check: Does the UE transmit RLC SDU#1 and RLC SDU#2? |
–> |
AMD PDU (RLC SDU#1, RLC SDU#2) |
1 |
P |
8 |
Void |
– |
– |
– |
– |
8A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=1) |
– |
– |
9 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#3 (AMD PDU#3 carries SDU#3 and SDU#4) containing the last 17 bytes of SDU#4 in its data field, with the P-bit set. FI=10, SO=51 and LSF=1. No header extension part is provided. |
<– |
AMD PDU#3 (SN=2, P=1) segment 2 |
– |
– |
9A |
100 ms after step 9 the SS assigns one default grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
10 |
The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#3. ACK_SN=3, NACK_SN=2, SOStart=0/SOEnd=50. |
–> |
STATUS PDU |
– |
– |
11 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#3 (AMD PDU#3 carries SDU#3 and SDU#4) containing SDU#3 (34 bytes) and the first 17 bytes of SDU#4 in its data field, with the P-bit set. FI=01, SO=0 and LSF=0. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=34. |
<– |
AMD PDU#3 (SN=2, P=1) segment 1 |
– |
– |
11A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns one default UL grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
12 |
Check: Does the UE transmit a STATUS PDU with ACK_SN=3? |
–> |
STATUS PDU |
3 |
P |
13 |
Void |
– |
– |
– |
– |
14 |
Check: Does the UE transmit RLC SDU#3 and RLC SDU#4? |
–> |
AMD PDU (RLC SDU#3, RLC SDU#4) |
1,5 |
P |
14A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=2) |
– |
– |
15 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#4 (AMD PDU#4 carries SDU#5) containing the first 17 bytes of SDU#5 in its data field. SO=0 and LSF=0. No header extension part is provided. |
<– |
AMD PDU#4 (SN=3) segment 1 |
– |
– |
16 |
The SS transmits an AMD PDU segment of AMD PDU#4 (AMD PDU#4 carries SDU#5) containing the first 17 bytes of SDU#5 in its data field. SO=0 and LSF=0. No header extension part is provided. |
<– |
AMD PDU#4 (SN=3) segment 1 |
– |
– |
17 |
The SS transmits an AMD PDU segment of AMD PDU#4 (AMD PDU#4 carries SDU#5) containing the last 17 bytes of SDU#5 in its data field, with the P-bit set. SO=17 and LSF=1. No header extension part is provided. |
<– |
AMD PDU#4 (SN=3, P=1) segment 2 |
– |
– |
17A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns one default UL grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
18 |
Check: Does the UE transmit a STATUS PDU with ACK_SN=4, thus acknowledging the reception of PDUs with SN=0 to SN=3, and no NACK_SN provided? |
–> |
STATUS PDU |
4 |
P |
19 |
Check: Does the UE transmit RLC SDU#5? |
–> |
(RLC SDU#5) |
1 |
P |
19A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=3) |
– |
– |
20 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#6 (AMD PDU#6 carries SDU#7) containing the last 17 bytes of SDU#7 in its data field, with the P-bit set. This AMD PDU segment is sent with SN=5. SO=17 and LSF=1. No header extension part is provided. |
<– |
AMD PDU#6 (SN=5, P=1) segment 2 |
– |
– |
20A |
100 ms after step 20 the SS assigns one default grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
21 |
Check: Does the UE transmit a STATUS PDU with ACK_SN=6, thus acknowledging the reception of PDUs with SN=0 to SN=5, and NACK_SN=4, E1/E2 field for receipt of PDU#5 and NACK_SN=5, SOStart=0/SOEnd=16 for segment 1 of PDU#6? |
–> |
STATUS PDU |
6 |
P |
22 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#6 (AMD PDU#6 carries SDU#7) containing the first 17 bytes of SDU#7 in its data field. SO=0 and LSF=0. No header extension part is provided. |
<– |
AMD PDU#6 (SN=5) segment 1 |
– |
– |
23 |
The SS transmits one AMD PDU containing SDU#6 (34 bytes) in its data field, with the P-bit set. |
<– |
AMD PDU#5 (SN=4, P=1) |
– |
– |
23A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns one default UL grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
24 |
The UE transmits a STATUS PDU with ACK_SN=6, thus acknowledging the reception of PDUs with SN=0 to SN=5, and no NACK_SN provided. |
–> |
STATUS PDU |
– |
– |
25 |
Void |
– |
– |
– |
– |
26 |
Check: Does the UE transmit RLC SDU#6 and RLC SDU#7? |
–> |
AMD PDU (RLC SDU#6, RLC SDU#7) |
2,5 |
P |
26A |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=4) |
– |
– |
27 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#7 (AMD PDU#7 carries SDU#8, SDU#9 and SDU#10) containing the last 8 bytes of SDU#9 and the complete SDU#10 (34 bytes) in its data field, with the P-bit set. FI=10, SO=60 and LSF=1. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=8. |
<– |
AMD PDU#7 (SN=6, P=1) segment 3 |
– |
– |
27A |
100 ms after step 27 the SS assigns one default grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
28 |
The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#7. ACK_SN=7, NACK_SN=6, SOStart=0/SOEnd=59. |
–> |
STATUS PDU |
– |
– |
29 |
After 100 ms the SS transmits an AMD PDU segment of AMD PDU#7 (AMD PDU#7 carries SDU#8, SDU#9 and SDU#10) containing the last 8 bytes of SDU#8 and the complete SDU#9 in its data field, with the P-bit set. FI=10, SO=26 and LSF=0. Header extension part present: E in fixed part header=1, E in extension part header=0, LI=8. |
<– |
AMD PDU#7 (SN=6, P=1) segment 2 |
– |
– |
29A |
30 ms after step 29 the SS assigns one default grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
30 |
The UE transmits a STATUS PDU NACK_SN field for receipt of PDU#7. ACK_SN=7, NACK_SN=6, SOStart=0/SOEnd=25. |
–> |
STATUS PDU |
7 |
P |
31 |
60 ms after step 29 the SS transmits an AMD PDU segment of AMD PDU#7 (AMD PDU#7 carries SDU#8, SDU#9 and SDU#10) containing the first 26 bytes of SDU#8 in its data field, with the P-bit set. SO=0 and LSF=0. No header extension part is provided. Note 4 |
<– |
AMD PDU#7 (SN=6, P=1) segment 1 |
– |
– |
31A |
The SS waits for 60 ms to ensure UE RLC has all the required SDUs available and then assigns one default UL grant (UL grant allocation type 3). |
<– |
(UL grant) |
– |
– |
32 |
Check: Does the UE transmit a STATUS PDU with ACK_SN=7, thus acknowledging the reception of PDUs with SN=0 to SN=6, and no NACK_SN provided? |
–> |
STATUS PDU |
7 |
P |
33 |
Void |
– |
– |
– |
– |
34 |
Void |
– |
– |
– |
– |
35 |
Check: Does the UE transmit RLC SDU#8, RLC SDU#9 and RLC SDU#10? |
–> |
AMD PDU (RLC SDU#8, RLC SDU#9, RLC SDU#10) |
7 |
P |
36 |
The SS transmits a STATUS PDU. |
<– |
STATUS PDU (ACK SN=5) |
– |
– |
Note 1: From steps 4 onwards, the transmission of AMD PDUs is scheduled. The activation time of 100 ms for the first of possibly several AMD PDUs is greater than t-StatusProhibit, and therefore there is no need to wait for the expiry of this timer.. Note 2: In steps 6-8, 12-14, 18-19, 24-26, 32-35 the STATUS PDU and the AMD PDU consisting of one or more RLC SDUs are received as a PDU list in one TTI. Note 3: In step 29A it is assumed that the UE will react upon the AMD PDU within 30 ms. Note 4: Step 31 shall be executed within 60 ms after step 29 to ensure that the UE receives the AMD PDU before the expiry of t-Reordering at the UE. |
7.2.3.18.3.3 Specific message contents
None.
7.2.3.19 Void
7.2.3.20 AM RLC / Duplicate detection of RLC PDUs
7.2.3.20.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE is in AM mode and receives duplicated RLC data PDUs having the same sequence number}
then { UE discards the duplicated RLC data PDUs }
}
7.2.3.20.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 4.2.1.3.3.
[TS 36.322, clause 4.2.1.3.3]
When the receiving side of an AM RLC entity receives RLC data PDUs, it shall:
– detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs;
…
7.2.3.20.3 Test description
7.2.3.20.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18].
7.2.3.20.3.2 Test procedure sequence
Table 7.2.3.20.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
1 |
SS creates 3 RLC SDUs of size 40 bytes segmented into two AMD PDUs each. AMD PDU#1 and AMD PDU#2 belong to RLC SDU#1, AMD PDU#3 and #4 belong to RLC SDU#2 and AMD PDU#5 and #6 belong to RLC SDU#3. SS transmits AMD PDU#1 with SN=0, AMD PDU#2 with SN=1 and AMD PDU#3 twice with SN=2. |
<– |
RLC AMD PDU#1 (SN=0) RLC AMD PDU#2 (SN=1) RLC AMD PDU#3 (SN=2) RLC AMD PDU#3 (SN=2) |
– |
– |
2 |
Check: Does the UE transmit RLC SDU#1? (Note 1) |
–> |
(RLC SDU#1) |
1 |
P |
3 |
SS transmits AMD PDU#4 with SN=3. |
<– |
RLC AMD PDU#4 (SN=3) |
– |
– |
4 |
Check: Does the UE transmit RLC SDU#2? |
–> |
(RLC SDU#2) |
1 |
P |
5 |
SS transmits AMD PDU#6 twice with SN=5. |
<– |
RLC AMD PDU#6 (SN=5) RLC AMD PDU#6 (SN=5) |
– |
– |
6 |
SS transmits AMD PDU#5 twice with SN=4. |
<– |
RLC AMD PDU#5 (SN=4) RLC AMD PDU#5 (SN=4) |
– |
– |
7 |
Check: Does the UE transmit RLC SDU#3 once? (Note 2) |
–> |
(RLC SDU#3) |
1 |
P |
Note 1: The duplicated AMD PDU#3 have been discarded by the conformant UE in step 1. Note 2: The duplicated AMD PDU#5 and AMD PDU#6 have been discarded by the conformant UE in steps 5 and 6. |
7.2.3.20.3.3 Specific message content
None.
7.2.3.21 AM RLC / RLC re-establishment at RRC connection reconfiguration including mobilityControlInfo IE
7.2.3.21.1 Test Purpose (TP)
(1)
with { UE in E-UTRA RRC_CONNECTED state }
ensure that {
when { UE is requested to perform a RRC Connection reconfiguration including mobilityControlInfo IE }
then { UE discards the remaining AMD PDUs; and discards all RLC SDUs in the transmitting side; and reset all state variables to their initial values. }
}
7.2.3.21.2 Conformance requirements
References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 5.4 and TS 36.331 clause 5.3.5.4.
[TS 36.322, clause 5.4]
RLC re-establishment is performed upon request by RRC, and the function is applicable for AM, UM and TM RLC entities.
When RRC indicates that an RLC entity should be re-established, the RLC entity shall:
…
– if it is an AM RLC entity:
– when possible, reassemble RLC SDUs from any byte segments of AMD PDUs with SN < VR(MR) in the receiving side, remove RLC headers when doing so and deliver all reassembled RLC SDUs to upper layer in ascending order of the RLC SN, if not delivered before;
– discard the remaining AMD PDUs and byte segments of AMD PDUs in the receiving side;
– discard all RLC SDUs and AMD PDUs in the transmitting side;
– discard all RLC control PDUs.
– stop and reset all timers;
– reset all state variables to their initial values.
[TS 36.331, clause 5.3.5.4]
If the RRCConnectionReconfiguration message includes the mobilityControlInfo and the UE is able to comply with the configuration included in this message, the UE shall:
….
1> re-establish RLC for all RBs that are established;
…
7.2.3.21.3 Test description
7.2.3.21.3.1 Pre-test conditions
System Simulator:
– Cell 1.
UE:
None.
Preamble:
– The UE is in state Loopback Activated (state 4) according to [18] with the exceptions listed in table 7.2.3.21.3.1-1.
Table 7.2.3.21.3.1-1: RLC settings
Parameter |
Value |
t-Reordering |
ms150 |
t-PollRetransmit |
ms150 |
7.2.3.21.3.2 Test procedure sequence
Table 7.2.3.21.3.2-1: Main behaviour
St |
Procedure |
Message Sequence |
TP |
Verdict |
|
U – S |
Message |
||||
– |
The SS ignores scheduling requests and does not allocate any uplink grant. |
– |
– |
– |
– |
1 |
SS creates 3 RLC SDUs of size 40 bytes segmented into two AMD PDUs each. AMD PDU#1 and AMD PDU#2 belong to RLC SDU#1, AMD PDU#3 and #4 belong to RLC SDU#2 and AMD PDU#5 and #6 belong to RLC SDU#3. SS transmits AMD PDU#1 (SN=0), AMD PDU#2 (SN=1) and AMD PDU#4 (SN=3). |
<– |
AMD PDU#1 AMD PDU#2 |
– |
– |
1A |
30 ms after step 1 the SS allocates 1 UL grant of default size (UL grant allocation type 3). |
<– |
(UL grant) |
||
2 |
The UE returns RLC SDU#1. |
–> |
(RLC SDU#1) |
– |
– |
3 |
SS does not acknowledge the reception of RLC SDU#1. |
– |
– |
– |
– |
4 |
90 ms after step 1 SS performs a RRC Connection Reconfiguration procedure including the mobilityControlInfo IE triggering RLC-reestablishment. (Note 1) |
– |
– |
– |
– |
4AA |
The SS starts the UL default grant transmissions |
– |
– |
– |
– |
4A |
The UE retransmits RLC SDU #1. (Note 1A) |
–> |
(RLC SDU#1) |
– |
– |
4B |
SS transmits a STATUS PDU (ACK_SN = 1). |
<– |
STATUS PDU |
– |
– |
5 |
SS transmits AMD PDU#5 with SN=0 and the P field set to "1" |
<– |
AMD PDU#5 |
– |
– |
6 |
Check: Does the UE transmit a STATUS PDU? (Note 2) |
–> |
STATUS PDU (ACK_SN = 1) |
1 |
P |
7 |
SS transmits AMD PDU#6 with SN=Receiving_AM_Window_Size+2 |
<– |
AMD PDU#6 |
– |
– |
8 |
Check: Does the UE return RLC SDU#3 within 1s? (Note 3) |
–> |
(RLC SDU#3) |
1 |
F |
9 |
SS transmits AMD PDU#6 with SN=1 |
<– |
AMD PDU#6 |
– |
– |
10 |
Check: Does the UE return RLC SDU#3 with its first AMD PDU set to SN=1? |
–> |
(RLC SDU#3) |
1 |
P |
Note 1: Upon a RLC re-establishment a conformant UE discards any remaining AMD PDUs in the receiver and transmitter side, stops and resets all timers and resets all state variables to their initial values. In case of CAT-M1 UEs an UL Grant of 56 bits will be provided to the UE. This is the same size as used in the regular RACH procedure. Note 1A: The UE will retransmit the PDCP SDU associated with RLC SDU#1 in accordance to TS 36.323 clause 5.2.1.1. Note 2: AMD PDU#4 is discarded by a conformant UE in step 4. Note 3: AMD PDU#6 is discarded by a conformant UE due to being outside the receiving window size. |
7.2.3.21.3.3 Specific message contents
Table 7.2.3.21.3.3-1: RRCConnectionReconfiguration (step 4, table 7.2.3.21.3.2-1)
Derivation Path: 36.508 table 4.6.1-8: RRCConnectionReconfiguration, condition HO |
|||
Information Element |
Value/remark |
Comment |
Condition |
RRCConnectionReconfiguration ::= SEQUENCE { |
|||
criticalExtensions CHOICE { |
|||
c1 CHOICE{ |
|||
rrcConnectionReconfiguration-r8 SEQUENCE { |
|||
mobilityControlInfo SEQUENCE { |
|||
targetPhysCellId |
Set to the physical cell identity of cell 1 |
||
carrierFreq |
Not present |
||
} |
|||
radioResourceConfigDedicated |
RadioResourceConfigDedicated-HO-MOD |
||
radioResourceConfigCommon |
Not present |
||
nonCriticalExtension SEQUENCE { |
CEmodeA CEmodeB |
||
lateNonCriticalExtension |
Not present |
||
nonCriticalExtension SEQUENCE { |
|||
otherConfig-r9 |
Not present |
||
fullConfig-r9 |
Not present |
||
nonCriticalExtension SEQUENCE { |
|||
sCellToReleaseList-r10 |
Not present |
||
sCellToAddModList-r10 |
Not present |
||
nonCriticalExtension SEQUENCE { |
|||
systemInformationBlockType1Dedicated-r11 |
SystemInformationBlockType1-BR-r13 of Cell 1 |
||
nonCriticalExtension |
Not present |
||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
|||
} |
Table 7.2.3.21.3.3-2: RadioResourceConfigDedicated-HO-MOD (Table 7.2.3.21.3.3-1)
Derivation Path: 36.508 table 4.6.3-19 |
|||
Information Element |
Value/remark |
Comment |
Condition |
RadioResourceConfigDedicated-HO-MOD ::= SEQUENCE { |
|||
physicalConfigDedicated |
PhysicalConfigDedicated-SR |
||
} |
Table 7.2.3.21.3.3-3: PhysicalConfigDedicated-SR (Table 7.2.3.21.3.3-2)
Derivation Path: 36.508, Table 4.8.2.1.6-1, condition RBC-HO |
|||||||
Information Element |
Value/remark |
Comment |
Condition |
||||
PhysicalConfigDedicated-DEFAULT ::= SEQUENCE { |
|||||||
schedulingRequestConfig |
SchedulingRequest-Config-DSR |
||||||
} |
|||||||
Table 7.2.3.21.3.3-4: SchedulingRequest-Config-DSR (Table 7.2.3.21.3.3-3)
Derivation Path: 36.508, Table 4.6.3.-20 |
|||
Information Element |
Value/remark |
Comment |
Condition |
SchedulingRequest-Config-DEFAULT ::= CHOICE { |
|||
setup SEQUENCE { |
|||
dsr-TransMax |
n32 |
||
} |
|||
} |