11 Elementary procedures
25.3223GPPRadio Link Control (RLC) protocol specificationRelease 17TS
Procedures defined in this clause are normative.
This description assumes elementary procedures. Interactions between procedures are not described.
11.1 Transparent mode data transfer procedure
11.1.1 General
The transparent mode data transfer procedure is used for transferring data between two RLC peer entities, which are operating in transparent mode. Data is transferred from Sender to Receiver. This procedure should only apply to entities in DATA_TRANSFER_READY state. Figure 11.1 below illustrates the elementary procedure for transparent mode data transfer.
Channels that can be used are DTCH, CCCH (uplink only), SHCCH (uplink only), BCCH and PCCH. The type of logical channel depends on if the RLC entity is located in the user plane (DTCH) or in the control plane (CCCH/BCCH/SHCCH/PCCH).
Figure 11.1: Transparent mode data transfer procedure
11.1.2 Transmission of TMD PDU
Upon a request of transparent mode data transfer from upper layer, the Sender shall:
– if no SDU discard configuration has been made by upper layers:
– discard SDUs received in previous TTIs upon reception of new SDUs from upper layers (see subclause 9.7.3.5);
– otherwise (if "Timer Based SDU Discard without explicit signalling" is configured):
– start a timer Timer_Discard for each SDU received from upper layers (see subclause 9.7.3);
– schedule the RLC SDUs that have been received from upper layer for transmission;
– if one or more RLC SDUs have been scheduled for transmission:
– notify the lower layer of reception of data from upper layers;
– perform the actions specified in subclause 11.1.2.2.
11.1.2.1 TMD PDU contents to set
The Sender shall set the data field of the TMD PDU to all or a subset of the data contained in the SDU as described in subclause 11.1.2.2.
11.1.2.2 Submission of TMD PDUs to the lower layer
If one or more RLC SDUs have been scheduled for transmission, according to subclause 11.1.2, the Sender shall:
– if it is configured for segmented operation:
– inform the lower layer of the size of the next SDU to be sent;
– segment the SDU according to the PDU size indicated by the lower layer.
– otherwise (the Sender is configured for non-segmented operation):
– inform the lower layer of the number and size of SDUs available for transmission;
– submit to the lower layer, the requested number of TMD PDUs;
– buffer the SDUs that are not submitted to the lower layer according to the discard configuration (see subclause 9.7.3).
11.1.3 Reception of TMD PDU
Upon delivery by the lower layer of a set of TMD PDUs (received within one TTI), the Receiver shall:
– if it is configured for segmented operation:
– reassemble the TMD PDUs received in one TTI into one RLC SDU.
– otherwise (it is configured for non-segmented operation):
– treat each received TMD PDU as a SDU;
– if "Delivery of Erroneous SDUs" is configured as "no":
– submit only the RLC SDUs received without error to upper layers through the TM-SAP.
– else if "Delivery of Erroneous SDUs" is configured as "yes":
– submit all RLC SDUs to upper layers through the TM-SAP;
– provide an error indication for each SDU received in error.
– otherwise if "Delivery of Erroneous SDUs" is configured as "No detect":
– submit all RLC SDUs to upper layers through the TM-SAP.
If segmentation is performed in transparent mode RLC, an SDU is erroneous if one or more of the TMD PDUs received in a TTI contains an error. If segmentation is not performed, an SDU is erroneous if the corresponding TMD PDU is erroneous.
11.1.4 Abnormal cases
11.1.4.1 Void
11.1.4.2 SDU discard without explicit signalling
Upon expiry of the timer Timer_Discard in the Sender, the Sender shall:
– discard the associated SDU;
– if requested:
– inform the upper layers of the discarded SDU.
In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDU.
11.2 Unacknowledged mode data transfer procedure
11.2.1 General
The unacknowledged mode data transfer procedure is used for transferring data between two RLC peer entities, which are operating in unacknowledged mode. Data is transferred from Sender to Receiver. This procedure should only apply to RLC entities in DATA_TRANSFER_READY state or LOCAL_SUSPEND state. Figure 11.2 below illustrates the elementary procedure for unacknowledged mode data transfer.
Channels that can be used are DTCH, DCCH, CCCH (downlink only), CTCH, SHCCH (downlink only), MCCH, MSCH, MTCH. The type of logical channel depends on if the RLC entity is located in the user plane (DTCH, CTCH, MTCH) or in the control plane (DCCH/CCCH(downlink only)/SHCCH(downlink only)/MCCH/MSCH). One or several PDUs may be transmitted in each transmission time interval (TTI). For each TTI, MAC decides which PDU size shall be used and how many PDUs shall be transmitted.
Figure 11.2: Unacknowledged mode data transfer procedure
11.2.2 Transmission of UMD PDU
Upon a request of unacknowledged mode data transfer from upper layer, the Sender shall:
– if no SDU discard configuration has been made by upper layers:
– only discard SDUs when the Transmission buffer is full (see subclause 9.7.3);
– if "Timer based SDU Discard without explicit signalling" is configured:
– start a timer Timer_Discard for each SDU received from upper layer (see subclause 9.7.3);
– schedule the RLC SDUs received from upper layer for transmission;
– if one or more RLC SDUs have been scheduled for transmission:
– notify the lower layer of reception of data from upper layers;
– perform the actions specified in subclause 11.2.2.2.
A UMD PDU shall be considered to be a padding PDU if it consists only of an RLC Header with one length indicator (indicating that the rest of the PDU is padding) and padding.
11.2.2.1 UMD PDU contents to set
The Sender shall:
– set the field "Sequence Number" equal to VT(US);
– set a "Length Indicator" field for each SDU that ends in the UMD PDU according to subclause 9.2.2.8.
For each "Extension bit" field in the RLC header, the Sender shall:
– if the next field in the UMD PDU is a "Length Indicator":
– set the "Extension bit" to "1";
– otherwise if the next field in the UMD PDU is data:
– set the "Extension bit" to "0".
11.2.2.2 Submission of UMD PDUs to the lower layer
If one or more SDUs have been scheduled for transmission according to subclause 11.2.2, the Sender shall:
– inform the lower layer of the number and size of SDUs scheduled for transmission;
– if "SN_Delivery" is configured:
– segment, but not concatenate SDUs
– else:
– segment, and if possible concatenate the SDUs according to the PDU sizes indicated by the lower layer (see subclause 9.2.2.9);
– submit to the lower layer, the requested number of UMD PDUs;
– update VT(US) for each UMD PDU submitted to the lower layer (see subclause 9.4);
– buffer the SDUs that are not submitted to the lower layer according to the discard configuration (see subclause 9.7.3).
11.2.3 Reception of UMD PDU
Upon delivery of a set of UMD PDUs from the lower layer or from the duplicate avoidance and reordering subentity, the Receiver shall:
– if "out of sequence SDU delivery" is configured:
– perform the actions specified in subclause 11.2.3.2;
– else:
– perform the actions specified in subclause 11.2.3.1.
11.2.3.1 SDU discard and re-assembly
Upon delivery of a set of UMD PDUs from the lower layer or from the duplicate avoidance and reordering subentity, the Receiver shall:
– if out-of-sequence reception is configured and SN ≥ VR(UM):
– discard the UMD PDU.
– else:
– update VR(US) according to each received UMD PDU (see subclause 9.4);
– if the updating step of VR(US) is not equal to one (i.e. one or more UMD PDUs are missing):
– discard the SDUs that could have segments or "Length Indicators" indicating the end of the SDUs in the missing UMD PDUs according to subclauses 9.2.2.8 and 9.2.2.9.
– if the special "Length Indicator" "1111 100" or "1111 1111 1111 100" is the first "Length Indicator" of a UMD PDU received on the downlink:
– consider the first data octet in this UMD PDU as the first octet of an RLC SDU.
– if the "Extension bit" indicates that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded:
– consider the data part in this UMD PDU as one complete RLC SDU.
– if the special "Length Indicator" "1111 101" or “1111 1111 1111 101” is the first "Length Indicator" of a UMD PDU received on the downlink:
– consider the first data octet in this UMD PDU as the first octet of an RLC SDU and the last data octet as the last octet of the same RLC SDU.
– if the special "Length Indicator" "1111 1111 1111 010" is the first "Length Indicator" of a UMD PDU received on the downlink:
– consider the first data octet in this UMD PDU as the first octet of an RLC SDU and the second last data octet as the last octet of the same RLC SDU.
– reassemble the received UMD PDUs into RLC SDUs;
– submit the RLC SDUs to upper layers through the UM-SAP.
11.2.3.2 Out of sequence SDU delivery
To enable the recovery of SDUs from UMD PDUs that are received in different transmissions the receiving function shall store PDUs until all SDUs that are associated with the PDU can be reconstructed or until they are discarded in accordance with the procedures described below. SDUs are transferred to the upper layers as soon as all PDUs that contain the segments of the SDU and the "Length Indicator" indicating the end of the SDU have been received.
Upon delivery of a set of UMD PDUs from the lower layer, the Receiver shall for each PDU (in the following SN denotes the sequence number of each PDU):
– If the PDU is the first PDU received (after the receiving entity is established or re-established or after Timer_OSD expires):
– VR(UOH) shall be assigned the value SN-1.
– if VR(UOH) > SN > VR(UOH) – OSD_Window_Size then:
– if a PDU with sequence number SN is already stored:
– discard the PDU;
– else:
– store the PDU in sequence number order.
– else:
– VR(UOH) shall be assigned the value SN, thereby advancing the storage window;
– store the PDU in sequence number order;
– remove from storage any PDUs whose sequence numbers, SN, are outside of the storage window VR(UOH) > SN > VR(UOH) – OSD_Window_Size;
– if Timer_OSD is active then Timer_OSD shall be stopped;
– Timer_OSD shall be started.
– if a PDU with sequence number SN was stored:
– if the PDU contains one or more complete SDUs and/or if the PDU contains segments of SDUs for which all the remaining segments and length indicators are contained in stored PDUs:
– re-assemble the SDUs;
– submit the SDUs to upper layers through the UM-SAP;
– remove from storage any PDUs which do not contain any segment of a SDU that has not been re-assembled, and do not contain one of the special length indicators "0000 000", "0000 0000 0000 000" or "1111 1111 1111 011" that indicate the end of a SDU that has not been re-assembled.
NOTE 0: If PDUs are removed from storage after SDU recovery then retransmitted PDUs may result in the duplicate transfer of SDUs to the higher layers.
– if Timer_OSD expires:
– remove from storage all stored PDUs.
NOTE 1: When configured for out of sequence SDU delivery, the transmitter should consider the possibility that a loss of a number of 128 OSD_Window_Size consecutively numbered PDUs may result in an undetected protocol error in the receiver, if the transmit state variable VT(US), at the end of a time interval equal to the duration of Timer_OSD, is greater than 128 + SN OSD_Window_Size + 1, where SN is the lowest sequence number of any PDU transmitted or retransmitted within that time interval.
NOTE 2: The transmitter should not concatenate within a single PDU, SDUs or fractions of SDUs that contain MBMS Access Information messages with SDUs or fractions of SDUs that contain other MCCH message types.
NOTE 3: SDUs are contained within consecutively numbered PDUs. To enable SDUs containing MBMS Access Information messages to be transmitted at their designated times, the transmitter may transmit PDUs out of sequence order.
NOTE 4: The transmitter should not transmit within a single PDU, SDUs or fractions of SDUs that contain MBMS Access Information messages with the special length indicator "0000 000","0000 0000 0000 000", and "1111 1111 1111 011".
11.2.4 Abnormal cases
11.2.4.1 Length Indicator value reserved for UMD PDU
Upon delivery by the lower layer of an UMD PDU that contains a "Length Indicator" value specified to be reserved for UMD PDUs in this version of the protocol, the Receiver shall:
– ignore that UMD PDU.
11.2.4.2 Invalid length indicator value
If the "Length Indicator" of an UMD PDU has a value that is larger than the PDU size – RLC header size and is not one of the predefined values listed in the table of subclause 9.2.2.8, the Receiver shall:
– ignore the UMD PDU.
11.2.4.3 SDU discard without explicit signalling
Upon expiry of the timer Timer_Discard in the Sender, the Sender shall:
– discard the associated SDU;
– if requested:
– inform the upper layers of the discarded SDU;
– for the first UMD PDU to be transmitted after the discard operation, the Sender shall:
– increment VT(US) so that the "Sequence Number" field in this UMD PDU is incremented with two compared with the previous UMD PDU;
– fill the first data octet in this UMD PDU with the first octet of an RLC SDU;
– if the "Extension bit" does not indicate that the UMD PDU contains a complete SDU which is not segmented, concatenated or padded:
– set the first "Length Indicator" in this UMD PDU to indicate that the previous RLC PDU was exactly filled with the last segment of an RLC SDU (to avoid that the Receiver unnecessarily discards an extra SDU).
In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may wait until after it provides MAC with the requested set of UMD PDUs before discarding the afore-mentioned SDU.
11.2.4.4 Invalid PDU size
In the UE, if the "DL RLC UM LI size" is configured to 7 bits, if a received UMD PDU has a size larger than 125 octets, the Receiver shall:
– ignore that UMD PDU.
11.3 Acknowledged mode data transfer procedure
11.3.1 General
The acknowledged mode data transfer procedure is used for transferring data between two RLC peer entities, which are operating in acknowledged mode. Data is transferred from Sender to Receiver. This procedure should only apply to RLC entities in DATA_TRANSFER_READY state or LOCAL_SUSPEND state. Figure 11.3 below illustrates the elementary procedure for acknowledged mode data transfer.
The AMD PDUs shall be transmitted on the DCCH logical channel if the Sender is located in the control plane and on the DTCH if it is located in the user plane. One or several PDUs may be transmitted in each transmission time interval (TTI) and MAC decides how many PDUs shall be transmitted in each TTI.
Figure 11.3: Acknowledged mode data transfer procedure
11.3.2 Transmission of AMD PDU
Upon a request of acknowledged mode data transfer from upper layers or upon retransmission of AMD PDUs, the Sender shall:
– when RLC SDUs are received from upper layers:
– if "fixed RLC PDU size" has been configured:
– segment, and if possible concatenate the RLC SDUs into AMD PDUs where the fixed PDU size is configured by upper layer (see subclause 9.2.2.9);
– if the last octet of the PDU is the last octet of an SDU and there is no SDU concatenation inside the PDU, and the “use of the special value of the HE field” has been configured by higher layers, set the HE field to indicate that the last octet of the PDU is the last octet of an SDU (see subclause 9.2.2.7).
– if "flexible RLC PDU size" has been configured:
– the last segment of an RLC SDU shall be concatenated with the first segment of the next RLC SDU in order to fill the data field at least up to the Minimum UL RLC PDU size. If data to be transmitted is not enough to create an AMD PDU of the minimum size, it is allowed to create an AMD PDU including all data to be transmitted, even if the resulting size is smaller than the Minimum UL RLC PDU size.
– set a "Length Indicator" field for each SDU that ends in the AMD PDU according to subclause 9.2.2.8, except for the SDUs where the end of the SDU has been indicated by the HE field according to subclause 9.2.2.7;
– if "Timer based SDU Discard with explicit signalling" is configured:
– start a timer Timer_Discard for each SDU received from upper layer (see subclause 9.7.3);
– schedule the AMD PDUs for transmission;
– for each AMD PDU which has been negatively acknowledged (see subclause 11.5.3):
– if the "Sequence Number" of the AMD PDU is less than VT(MS):
– schedule the AMD PDU for retransmission;
– if a poll has been triggered by one of configured polling functions (see subclause 9.7.1); and
– if polling is not prohibited (see subclause 9.5); and
– if no AMD PDU is scheduled for transmission or retransmission; and
– if there is at least one PDU that has been transmitted, has not been discarded and has not yet been acknowledged:
– if the value of "Configured_Tx_Window_Size" is larger than or equal to "2048":
– select the AMD PDU with "Sequence Number" equal to VT(S)-1; or
– assemble a POLL SUFI according to subclause 9.2.2.11.9 when "flexible RLC PDU size" is configured;
– otherwise if the "Configured_Tx_Window_Size" is less than "2048":
– select the AMD PDU with "Sequence Number" equal to VT(S)-1; or
– select an AMD PDU that has not been discarded and has not yet been acknowledged by the peer entity; or
– assemble a POLL SUFI according to subclause 9.2.2.11.9 when “flexible RLC PDU size” is configured;
– if an AMD PDU was selected, schedule the selected AMD PDU for retransmission (in order to transmit a poll), or if a POLL SUFI was assembled, schedule a STATUS PDU containing the POLL SUFI for transmission:
– if the timer Timer_Poll is configured:
– start the timer Timer_Poll according to subclause 9.5.
NOTE 1: In downlink, if "flexible RLC PDU size" is configured, the UTRAN should segment, and if possible concatenate the RLC SDUs into AMD PDUs with a size not larger than the maximum RLC PDU size.
NOTE 2: In downlink, UTRAN can initiate the Polling function by assembling a POLL SUFI when "flexible RLC PDU size" in downlink is configured. If a POLL SUFI was assembled, UTRAN should schedule and submit to lower layer a STATUS PDU containing the POLL SUFI.
NOTE 3: In uplink, the UE can initiate the Polling function by assembling a POLL SUFI according to subclause 9.2.2.11.9 when "flexible RLC PDU size" in uplink is configured. If a POLL SUFI was assembled, the UE should schedule and submit to lower layer a STATUS PDU containing the POLL SUFI.
Each time an AMD PDU is scheduled for transmission or retransmission, the Sender shall:
– increment the value of the corresponding VT(DAT);
– if VT(DAT) = MaxDAT:
– perform the actions specified in subclause 11.3.3a;
– e1se:
– notify the lower layer that data is available for transmission;
– perform the actions specified in subclause 11.3.2.2.
In AM, a PDU shall be considered to be a padding PDU if it is:
– an AMD PDU consisting only of an RLC Header with one "Length Indicator" (indicating that the rest of the PDU is padding) and padding; or
– a STATUS PDU consisting only of a NO_MORE SUFI.
11.3.2.1 AMD PDU contents to set
If the AMD PDU is transmitted for the first time, the Sender shall:
– set the "Sequence Number" field equal to VT(S);
– if the last octet of the PDU is the last octet of an SDU and there is no SDU concatenation inside the PDU, and the use of the special value of HE field has been configured by higher layers, set the HE field to indicate that the last octet of the PDU is the last octet of an SDU (see subclause 9.2.2.7)
– set a "Length Indicator" field for each SDU that ends in the AMD PDU according to subclause 9.2.2.8, except for the SDUs where the end of the SDU has been indicated by the HE field according to subclause 9.2.2.7;
– set the "Polling bit" to the value specified in subclause 11.3.2.1.1.
Otherwise if the AMD PDU is retransmitted:
– use the same value of the "Sequence Number" field as in the original transmission of the AMD PDU;
– if the "Length Indicator" fields needed in the AMD PDU according to subclause 9.2.2.8 has changed due to that a piggybacked STATUS PDU is included in the AMD PDU or a piggybacked STATUS PDU was included in the previous transmission of the AMD PDU:
– update the "Length Indicator" fields according to 9.2.2.8.
– set the "Polling bit" to the value specified in subclause 11.3.2.1.1.
11.3.2.1.1 Setting of the Polling bit
The Sender shall:
– if a poll has been triggered by one or several poll triggers (see subclause 9.7.1):
– if polling is not prohibited, see subclause 9.5:
– set the "Polling bit" in the AMD PDU header to "1";
– otherwise:
– set the "Polling bit" in the AMD PDU header to "0".
11.3.2.1.2 Void
11.3.2.2 Submission of AMD PDUs to lower layer
If one or more AMD PDUs have been scheduled for transmission or retransmission according to subclause 11.3.2, the Sender shall:
– not submit any AMD PDUs to lower layer that is not allowed to transmit. AMD PDUs are only allowed to transmit:
– if the AMD PDU has a "Sequence Number" < VT(MS) or the AMD PDU has a "Sequence Number" equal to VT(S)-1; and
– if the AMD PDU is not restricted to be transmitted by the local suspend function, see subclause 9.7.5.
– inform the lower layer of both the numbers of AMD PDUs scheduled and allowed for transmission or retransmission;
– set the AMD PDU contents according to subclause 11.3.2.1;
– submit to the lower layer the requested number of AMD PDUs;
– treat retransmissions with higher priority than AMD PDUs transmitted for the first time;
– update the state variables in clause 9.4 for each AMD PDU submitted to lower layer except VT(DAT) which has already been updated, see subclause 11.3.2;
– if the "Polling bit" is set to "1" in any of the AMD PDUs; and
– if the timer Timer_Poll is configured;
– start the timer Timer_Poll according to subclause 9.5;
– buffer the AMD PDUs that are not submitted to the lower layer according to the discard configuration (see subclause 9.7.3).
11.3.3 Reception of AMD PDU by the Receiver
Upon reception of an AMD PDU, the Receiver shall:
– in the UE if "fixed RLC PDU size" has been configured:
– if the "downlink AMD PDU size" has not yet been set:
– set the "downlink AMD PDU size" to the size of the received PDU.
– update VR(R), VR(H) and VR(MR) state variables for each received AMD PDU (see clause 9.4);
– if Timer_Reordering is configured:
– if a received AMD PDU SN = VR(MS)
– update VR(MS) to SN of the first AMD PDU that has not been received;
– if Timer_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 Timer_Reordering;
– if Timer_Reordering is not running (includes the case Timer_Reordering is stopped due to actions above):
– if VR (H) > VR(R):
– start Timer_Reordering;
– set VR(X) to VR(H).
– if a received AMD PDU includes a "Polling bit" set to "1", or "Missing PDU Indicator" is configured and the Receiver detects that a PDU is missing:
– initiate the STATUS PDU transfer procedure;
– reassemble the received AMD PDUs into RLC SDUs;
– if "In-Sequence Delivery" is configured:
– deliver the RLC SDUs in-sequence (i.e. in the same order as the RLC SDUs were originally transmitted by the peer entity) to upper layers through the AM-SAP.
– otherwise:
– deliver the RLC SDUs in arbitrary order to upper layers through the AM-SAP.
11.3.3a Reached maximum number of attempts
If VT(DAT) = MaxDAT, the Sender shall:
– if "No_discard after MaxDAT number of transmissions" is configured:
– initiate the RLC reset procedure, see subclause 11.4.
– if "SDU discard after MaxDAT number of transmissions" is configured:
– initiate the "SDU discard with explicit signalling" procedure for the corresponding SDU, see subclause 11.6.
11.3.4 Abnormal cases
11.3.4.1 Void
11.3.4.2 Receiving an AMD PDU outside the reception window
Upon reception of an AMD PDU with "Sequence Number" outside the interval VR(R)SN<VR(MR), the Receiver shall:
– discard the AMD PDU;
– if the "polling bit" in the discarded AMD PDU is set to "1":
– initiate the STATUS PDU transfer procedure.
11.3.4.3 Timer_Discard timeout
11.3.4.3.1 SDU discard with explicit signalling
Upon expiry of the timer Timer_Discard, the Sender shall:
– initiate the SDU discard with explicit signalling procedure, see subclause 11.6.2.
In the case where the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the UE may wait until after it provides MAC with the requested set of PDUs before discarding the afore-mentioned SDUs.
11.3.4.4 Void
11.3.4.5 Invalid length indicator value
If the "Length Indicator" of an AMD PDU has a value that is larger than the PDU size – RLC header size and is not one of the predefined values listed in the table of subclause 9.2.2.8, the Receiver shall:
– ignore that AMD PDU.
11.3.4.6 Length Indicator value reserved for AMD PDU
Upon delivery by the lower layer of an AMD PDU that contains a "Length Indicator" value specified to be reserved for AMD PDUs in this version of the protocol, the Receiver shall:
– ignore that AMD PDU.
11.3.4.7 Void
11.3.4.8 Receiving an AMD PDU within the reception window more than once (Handling of Duplicates)
Upon reception of an AMD PDU with a “Sequence Number” within the interval VR(R)SN<VR(MR), for which "Sequence Number" an AMD PDU has already been received, the Receiver shall:
– discard the AMD PDU;
– consider the AMD PDU with this "Sequence Number" as having been correctly received in the next status report to be transmitted;
– – if the "polling bit" in the discarded AMD PDU is set to "1":
– initiate the STATUS PDU transfer procedure.
– if a piggybacked STATUS PDU is included in the AMD PDU:
– perform the actions specified in subclause 11.5.3.
11.3.4.9 Full Buffer Behavior
It is foreseen that in some conditions, e.g. when the window size is re-configured, the UE may have memory limitations.
While the buffer memory is full:
– the UE is not required to segment RLC SDUs into AMD PDUs as per Subclause 11.3.2;
– the UE shall:
– be able to process incoming AMD PDUs (especially to be able to process and store the AMD PDU with "Sequence Number" = VR(R));
– operate according to the normal protocol, e.g. process STATUS reports and perform retransmissions;
– the UE may discard received AMD PDUs with "Sequence Number" within the receiving window and consider the discarded AMD PDUs as not having been received.
11.3.4.10 Invalid PDU size
In the UE, if "fixed RLC PDU size" has been configured and if a received AMD PDU has a size different from the configured "downlink AMD PDU size", the Receiver shall:
– ignore that AMD PDU.
11.3.5 Transmission of POLL SUFI
Each time a STATUS PDU containing the POLL SUFI is scheduled for transmission, the Sender shall:
– increment the value of the corresponding VT(DAT) of the AMD PDU with sequence number equal to VT(S)-1;
– if VT(DAT) = MaxDAT:
– perform the actions specified in subclause 11.3.3a;
– e1se:
– notify the lower layer that STATUS PDU is available for transmission.
11.4 RLC reset procedure
11.4.1 General
The RLC reset procedure is used to reset two RLC peer entities, which are operating in acknowledged mode. Figure 11.4 below illustrates the elementary procedure for an RLC reset. During the reset procedure the hyper frame numbers (HFN) in UTRAN and UE are synchronised. Two HFNs used for ciphering needs to be synchronised, DL HFN in downlink and UL HFN in uplink. In the reset procedure, the highest UL HFN and DL HFN used by the RLC entity in the transmitting sides, i.e. the HFNs associated with AMD PDUs of "Sequence Number"=VT(S)-1 if at least one AMD PDU had been transmitted or of "Sequence Number"=0 if no AMD PDU had been transmitted, are exchanged between UE and UTRAN.
The RESET PDUs and the RESET ACK PDUs have higher priority than AMD PDUs.
Figure 11.4: RLC reset procedure
11.4.2 Initiation
The Sender shall:
– if one of the following triggers is detected:
1) "No_Discard after MaxDAT number of transmissions" is configured and VT(DAT) equals the value MaxDAT (see subclause 9.7.3.4);
2) VT(MRW) equals the value MaxMRW;
3) A STATUS PDU or a piggybacked STATUS PDU including "erroneous Sequence Number" is received (see clause 10);
– stop transmitting any AMD PDU or STATUS PDU;
– ignore any incoming AMD PDU, piggybacked STATUS PDU or STATUS PDU;
– increment VT(RST) by 1;
– if VT(RST) = MaxRST:
– perform the actions specified in subclause 11.4.4a.
– else (if VT(RST) < MaxRST):
– submit a RESET PDU to the lower layer;
– start the timer Timer_RST according to the description in subclause 9.5.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the RLC reset procedure until the end of the next TTI.
When a reset procedure has been initiated it can only be ended upon reception of a RESET ACK PDU with the same RSN value as in the corresponding RESET PDU, upon request of re-establishment due to request of re-establishment (for the whole RLC entity or for only the transmitting or receiving side of the RLC entity), or release from upper layer. A reset procedure is not interrupted by the reception of a RESET PDU from the peer entity.
11.4.2.1 RESET PDU contents to set
The Sender shall:
– set the HFNI field to the currently highest used HFN (DL HFN when the RESET PDU is sent by UTRAN or UL HFN when the RESET PDU is sent by the UE);
– set the RSN field to the sequence number of the RESET PDU. The sequence number of the first RESET PDU after the AM entity is established or re-established (for the whole RLC entity or for only the transmitting or receiving side of the RLC entity) shall be "0". This sequence number is incremented every time a new RESET PDU is transmitted, but not when a RESET PDU is retransmitted.
11.4.3 Reception of the RESET PDU by the Receiver
Upon reception of a RESET PDU the Receiver shall:
– if the RESET PDU is not the first RESET PDU received since the entity was established or re-established; and
– if the RSN value in the RESET PDU is the same as the RSN value in the last received RESET PDU:
– only submit a RESET ACK PDU to the lower layer with the contents set exactly as in the last transmitted RESET ACK PDU (i.e., in this case the RLC entity is not reset).
– if the RESET PDU is the first RESET PDU received since the entity was established or re-established; or
– if the RSN value is different from the RSN value in the last received RESET PDU:
– submit a RESET ACK PDU to the lower layer with the content set as specified in subclause 11.4.3.1;
– reset the state variables described in subclause 9.4 except VT(RST) to their initial values;
– stop all the timers described in subclause 9.5 except Timer_RST, Timer_Discard, Timer_Poll_Periodic and Timer_Status_Periodic;
– reset configurable parameters to their configured values;
– discard all RLC PDUs in the receiving side of the AM RLC entity;
– discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC entity;
– if requested for the transmitting side:
– inform the upper layers of the discarded SDUs.
– set the HFN (DL HFN when the RESET PDU is received in UE or UL HFN when the RESET PDU is received in UTRAN) equal to the HFNI field in the received RESET PDU;
– increase with one the UL HFN and DL HFN, and the updated HFN values shall be used for the first transmitted and received AMD PDUs after the reset procedure.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the RLC SDUs discard in the transmitting side of the AM RLC entity until the end of the next TTI.
11.4.3.1 RESET ACK PDU contents to set
The RLC entity shall:
– set the hyper frame number indicator field (HFNI) to the currently highest used HFN (DL HFN when the RESET ACK PDU is sent by UTRAN or UL HFN when the RESET ACK PDU is sent by the UE);
– set the RSN field to the same value as in the corresponding received RESET PDU.
11.4.4 Reception of the RESET ACK PDU by the Sender
Upon reception of a RESET ACK PDU, the Sender shall:
– if the Sender has already transmitted a RESET PDU which has not been yet acknowledged by a RESET ACK PDU:
– if the received RSN value is the same as the one in the corresponding RESET PDU:
– set the HFN value (DL HFN when the RESET ACK PDU is received in UE or UL HFN when the RESET ACK PDU is received in UTRAN) to the HFNI field of the received RESET ACK PDU;
– reset the state variables described in subclause 9.4 to their initial values;
– stop all the timers described in subclause 9.5 except Timer_Discard, Timer_Poll_Periodic and Timer_Status_Periodic;
– reset configurable parameters to their configured values;
– discard all RLC PDUs in the receiving side of the AM RLC entity;
– discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC entity;
– if requested for the transmitting side:
– inform the upper layers of the discarded SDUs.
– increase with one the UL HFN and DL HFN, and the updated HFN values shall be used for the first transmitted and received AMD PDUs after the reset procedure;
– otherwise (if the received RSN value is not the same as the one in the corresponding RESET PDU):
– discard the RESET ACK PDU;
– otherwise (if the Sender has not transmitted a RESET PDU which has not been yet acknowledged by a RESET ACK PDU):
– discard the RESET ACK PDU.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the RLC SDUs discard in the transmitting side until the end of the next TTI.
11.4.4a Reached maximum number of attempts
If VT(RST) = MaxRST, the Sender shall:
– terminate the ongoing RLC RESET procedure;
– stop the timer Timer_RST if it was started;
– indicate unrecoverable error to upper layer.
11.4.5 Abnormal cases
11.4.5.1 Timer_RST timeout
If Timer_RST expires before the reset procedure is terminated, the Sender shall:
– increment VT(RST) by one;
– if VT(RST)<MaxRST:
– set the RESET PDU as previously transmitted;
– transmit the RESET PDU;
– restart Timer_RST according to the description in subclause 9.5.
– else (if VT(RST) = MaxRST):
– perform the actions specified in subclause 11.4.4a.
11.4.5.2 Void
11.4.5.3 Reception of the RESET PDU by the Sender
Upon reception of a RESET PDU, the Sender shall:
– submit a RESET ACK PDU to the lower layer with the content set as specified in subclause 11.4.3.1;
– reset the state variables described in subclause 9.4 except VT(RST) to their initial values;
– stop all the timers described in subclause 9.5 except Timer_RST, Timer_Discard, Timer_Poll_Periodic and Timer_Status_Periodic;
– reset configurable parameters to their configured values;
– discard all RLC PDUs in the receiving side of the AM RLC entity;
– discard all RLC SDUs that were transmitted before the reset in the transmitting side of the AM RLC entity;
– if requested for the transmitting side:
– inform the upper layers of the discarded SDUs.
– set the HFN (DL HFN when the RESET PDU is received in UE or UL HFN when the RESET PDU is received in UTRAN) equal to the HFNI field in the received RESET PDU.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the RLC SDUs discard in the transmitting side until the end of the next TTI.
11.5 STATUS report transfer procedure
11.5.1 General
The status report transfer procedure is used for transferring of status information between two RLC peer entities, which are operating in acknowledged mode. Figure 11.5 below illustrates the elementary procedure for status report transfer. A status report consists of one or several STATUS PDUs.
In case two logical channels are configured in the uplink, only acknowledgement status reports, MRW ACK SUFI and WINDOW SUFI shall be transmitted on the second logical channel. In case two logical channels are configured in the downlink, control PDUs can be transmitted on any of the two logical channels.
The STATUS PDUs have higher priority than AMD PDUs.
Figure 11.5: Status report transfer procedure
11.5.2 Initiation
The Receiver shall:
– if one of the following triggers is detected:
1) The "Polling bit" in a received AMD PDU is set to "1";
2) "Missing PDU Indicator" is configured and a missing AMD PDU is detected;
3) The "Timer based STATUS transfer" is configured and the timer Timer_Status_Periodic has expired:
– act on the trigger as specified in subclause 9.7.2.
4) Void
5) If the flexible RLC PDU size is configured and POLL SUFI is received:
– consider that Poll_SN has been transmitted by the sender as specified in subclause 9.4:
– act on the trigger as specified in subclause 9.7.2.
11.5.2.1 Piggybacked STATUS PDU
The Receiver may:
– if STATUS PDU(s) to be sent fit into padding octets in AMD PDU(s) to be sent:
– piggyback a STATUS PDU on the AMD PDU to be sent.
Submission of a piggybacked STATUS PDU in an AMD PDU to the lower layer follows the same rules as an ordinary STATUS PDU.
11.5.2.2 STATUS PDU contents to set
On triggering of a status report, the Receiver shall:
– if the "STATUS prohibit" is not active:
– If Timer_Reordering is not configured:
– include negative acknowledgements for all AMD PDUs detected as missing;
– include an ACK SUFI positively acknowledging all AMD PDUs received up to at least VR(R);
– If Timer_Reordering is configured, for all SN such that VR(R) <= SN < VR(MS):
– include negative acknowledgements for all AMD PDUs detected as missing;
– include an ACK SUFI positively acknowledging all AMD PDUs received up to at least VR(R);
– if an MRW SUFI assembled as specified in subclause 11.6.2.2 had not been sent:
– optionally include the MRW SUFI;
– if an MRW_ACK SUFI assembled as specified in subclause 11.6.2.2 is awaiting transmission:
– optionally include the MRW_ACK SUFI;
– if the Sender’s transmission window is to be updated:
– optionally include the WINDOW SUFI;
– if all SUFIs can be accommodated in one STATUS PDU:
– construct the status report using one STATUS PDU, using one of the allowed PDU sizes;
– if the SUFIs included do not fill the entire STATUS PDU:
– if the STATUS PDU is not terminated with an ACK SUFI:
– terminate the STATUS PDU with a NO_MORE SUFI.
– use padding in the remainder of the STATUS PDU (padding size may be zero);
– otherwise (the status report is segmented):
– construct STATUS PDUs including only complete SUFIs using one of the allowed PDU sizes. The set of STATUS PDUs shall accommodate all the SUFIs to form the complete status report. Indication of the same AMD PDU shall not be given in more than one STATUS PDU of a status report, but the ACK SUFI can be present in more than one STATUS PDU of a status report;
– if any STATUS PDU constructed is not entirely filled with SUFIs:
– if the STATUS PDU is not terminated with an ACK SUFI:
– terminate that STATUS PDU with a NO_MORE SUFI.
– use padding in the remainder of that STATUS PDU (padding size may be zero).
Which SUFI fields to use is implementation dependent. Bitmap SUFI is used to indicate both received and/or missing AMD PDUs. List SUFI and/or Relative List SUFI are used to indicate missing AMD PDUs only. Acknowledgement SUFI is used to indicate the received AMD PDUs. (For SUFI details see 9.2.2.11.)
11.5.2.3 Submission of STATUS PDUs to the lower layer
The Receiver shall:
– inform the lower layer of the STATUS PDUs scheduled for transmission;
– submit to the lower layer, the requested number of PDUs (STATUS PDUs, piggybacked AMD/STATUS PDUs and optionally AMD PDUs, see also subclause 11.3.2.2);
– if "Timer based STATUS transfer" is configured and the timer Timer_Status_Periodic has expired:
– restart the timer Timer_Status_Periodic according to subclause 9.5 f);
– if the STATUS PDU includes the MRW SUFI:
– start the timer Timer_MRW according to subclause 9.5 i).
11.5.3 Reception of the STATUS PDU by the Sender
Upon reception of the STATUS PDU/piggybacked STATUS PDU, the Sender shall:
– if an RLC SDU is positively acknowledged by the STATUS PDU:
– if requested:
– inform the upper layers of the reception of the RLC SDU by the peer AM RLC entity.
– update the state variables VT(A) and VT(MS) according to the received STATUS PDU/piggybacked STATUS PDU;
– if the STATUS PDU includes negatively acknowledged AMD PDUs:
– initiate the acknowledged data transfer procedure; and
– retransmit these AMD PDUs. Retransmitted AMD PDUs shall have higher priority than AMD PDUs to be transmitted for the first time;
– if an AMD PDU is negatively acknowledged more than once in a STATUS PDU:
– retransmit the AMD PDU only once.
– if the STATUS PDU includes the MRW SUFI:
– take the actions specified in subclause 11.6.3.
– if the STATUS PDU includes the MRW_ACK SUFI:
– take the actions specified in subclause 11.6.4.
– if the STATUS PDU includes the WINDOW SUFI:
– update the current transmission window size, VT(WS).
11.5.4 Abnormal cases
11.5.4.1 Void
11.6 SDU discard with explicit signalling procedure
11.6.1 General
The SDU discard with explicit signalling procedure is used for discarding SDUs and transferring the discard information between two peer entities, which are operating in acknowledged mode. The Sender shall discard an SDU that has not been successfully transmitted for a period of time or for a number of transmissions, and send a Move Receiving Window (MRW) SUFI to the Receiver. According to the MRW SUFI, the Receiver shall discard AMD PDUs carrying that SDU and update the reception window. Figure 11.6 below illustrates the elementary procedure for SDU discard with explicit signalling.
Figure 11.6: SDU discard with explicit signalling
11.6.2 Initiation
The Sender shall initiate the SDU discard with explicit signalling procedure if one of the following triggers is detected:
– "Timer based SDU discard with explicit signalling" is configured, Timer_Discard expires for an SDU, and one or more segments of the SDU have been submitted to lower layer;
– "Timer based SDU discard with explicit signalling" is configured, Timer_Discard expires for an SDU, and "Send MRW" is configured;
– "SDU discard after MaxDAT number of transmissions" is configured, and MaxDAT number of transmissions is reached (i.e. VT(DAT) MaxDAT) for an AMD PDU.
Upon initiation of the SDU discard with explicit signalling procedure, the Sender shall:
– if "Timer based SDU discard with explicit signalling" is configured:
– discard all SDUs up to and including the SDU for which the timer Timer_Discard expired.
– if "SDU discard after MaxDAT number of transmissions" is configured:
– discard all SDUs that have segments or "Length Indicators" indicating the end of the SDUs in AMD PDUs with "Sequence Number" SN inside the interval VT(A) SN X, where X is the value of the "Sequence Number" of the AMD PDU with VT(DAT) MaxDAT.
– if requested:
– inform the upper layers of the discarded SDUs
– discard all AMD PDUs including segments of the discarded SDUs or "Length Indicators" indicating the end of the SDUs, unless they also carry a segment of a SDU which is not discarded;
– if more than 15 discarded SDUs are to be informed to the Receiver (see subclause 11.6.2.2):
– if "Send MRW" is not configured:
– assemble an MRW SUFI with the discard information of the SDUs.
– otherwise ("Send MRW" is configured):
– assemble an MRW SUFI with the discard information of the first 15 SDUs; and
– include the discard information of the rest SDUs in another MRW SUFI which shall be sent by the next SDU discard with explicit signalling procedure (after the current SDU discard with explicit signalling procedure is terminated).
– otherwise (less than or equal to 15 discarded SDUs are to be informed to the Receiver):
– assemble an MRW SUFI with the discard information of the SDUs.
– schedule and submit to lower layer a STATUS PDU/piggybacked STATUS PDU containing the MRW SUFI;
– if SN_MRWLENGTH in the MRW SUFI >VT(S):
– update VT(S) to SN_MRWLENGTH.
– start a timer Timer_MRW according to subclause 9.5.
If a new SDU discard with explicit signalling procedure is triggered when the current SDU discard with explicit signalling procedure is still going on, no new MRW SUFIs shall be sent before the current SDU discard with explicit signalling procedure is terminated by one of the termination criteria specified in subclause 11.6.4.
11.6.2.1 Void
11.6.2.2 STATUS PDU contents to set
The Sender shall:
– if "Send MRW" is configured:
– if no new SDU is present inside the AMD PDU which contains the "Length Indicator" of the last discarded SDU or if the AMD PDU contains the special value of the HE field to indicate the end of the last discarded SDU:
– set the last SN_MRWi field in the MRW SUFI to 1 + "Sequence Number" of the AMD PDU which contains the "Length Indicator" of the last discarded SDU or the special value of the HE field to indicate the end of the last discarded SDU;
– set the NLENGTH field in the MRW SUFI to "0000".
– otherwise:
– set the last SN_MRWi field in the MRW SUFI to the "Sequence Number" of the AMD PDU which contains the "Length Indicator" of the last discarded SDU;
– set the NLENGTH field in the MRW SUFI so that the last data octet to be discarded in the Receiver shall be the octet indicated by the NLENGTH:th "Length Indicator" field of the AMD PDU which contains the "Length Indicator" of the last discarded SDU;
– set each of the other SN_MRWi fields in the MRW SUFI to the "Sequence Number" of the AMD PDU which contains the "Length Indicator" of the i:th discarded SDU or the special value of the HE field to indicate the end of the i:th discarded SDU.
– otherwise ("Send MRW" is not configured):
– if no new SDU is present inside the AMD PDU which contains the "Length Indicator" of the last discarded SDU or if the AMD PDU contains the special value of the HE field to indicate the end of the last discarded SDU:
– set the last SN_MRWi field in the MRW SUFI to 1 + "Sequence Number" of the AMD PDU which contains the "Length Indicator" of the last SDU to be discarded in the Receiver or the special value of the HE field to indicate the end of the last discarded SDU;
– set the NLENGTH field in the MRW SUFI to "0000".
– otherwise:
– set the last SN_MRWi field in the MRW SUFI to the "Sequence Number" of the AMD PDU which contains the "Length Indicator" of the last SDU to be discarded in the Receiver;
– set the NLENGTH field in the MRW SUFI so that the last data octet to be discarded in the Receiver shall be the octet indicated by the NLENGTH:th "Length Indicator" field of the AMD PDU which contains the "Length Indicator" of the last SDU to be discarded in the Receiver;
– optionally set each of the other SN_MRWi fields in the MRW SUFI to the "Sequence Number" of the AMD PDU which contains the "Length Indicator" or the special value of the HE field to indicate the end of the i:th SDU to be discarded in the Receiver;
– if the MRW SUFI contains only one SN_MRWi field and the value of SN_MRWi field VT(A)+Configured_Tx_Window_Size:
– set the LENGTH field in the MRW SUFI to "0000".
– otherwise:
– set the LENGTH field in the MRW SUFI to the number of SN_MRWi fields in the same MRW SUFI. In this case, SN_MRW1 shall be in the interval VT(A) SN_MRW1 < VT(A)+Configured_Tx_Window_Size.
11.6.3 Reception of the STATUS PDU by the Receiver
Upon reception of the STATUS PDU/piggybacked STATUS PDU containing an MRW SUFI, the Receiver shall:
– if the LENGTH field in the received MRW SUFI is "0000":
– consider SN_MRW1 to be above or equal to VR(R).
– otherwise:
– consider SN_MRW1 to be less than VR(MR);
– consider all the SN_MRWis other than SN_MRW1 to be in sequential order within the list and sequentially above or equal to SN_MRWi-1;
– deliver all the successfully received SDUs from the SDU that have segments or "Length Indicators" indicating the end of the SDUs in AMD PDU with "Sequence Number" of VR(R) up to and including the last SDU that is indicated by the MRW SUFI;
– discard AMD PDUs up to and including the PDU with sequence number SN_MRWLENGTH–1;
– if the NLENGTH field in the received MRW SUFI is "0000":
– reassemble from the first data octet of the AMD PDU with sequence number SN_MRWLENGTH after the discard.
– otherwise:
– discard further the data octets in the AMD PDU with sequence number SN_MRWLENGTH up to and including the octet indicated by the NLENGTH:th "Length Indicator" field of the PDU with sequence number SN_MRWLENGTH;
– reassemble from the succeeding data octet in the AMD PDU with sequence number SN_MRWLENGTH after the discard;
– if "Send MRW" is configured:
– inform upper layers about all of the discarded SDUs that were not previously delivered to upper layer or discarded by other MRW SUFIs;
– update the state variables VR(R), VR(H) and VR(MR) according to the received STATUS PDU/piggybacked STATUS PDU;
– assemble a MRW_ACK SUFI according to subclause 11.6.3.1;
– schedule and submit to lower layer a STATUS PDU/piggybacked STATUS PDU containing the MRW_ACK SUFI.
11.6.3.1 STATUS PDU contents to set
The Receiver shall:
– set the SN_ACK field in the MRW_ACK SUFI to the new value of VR(R), updated after reception of the MRW SUFI;
– if the SN_ACK field in the MRW_ACK SUFI is set equal to the SN_MRWLENGTH field in the received MRW SUFI:
– set the N field in the MRW_ACK SUFI to the NLENGTH field in the received MRW SUFI.
– otherwise:
– set the N field in the MRW_ACK SUFI to "0000".
– include the MRW_ACK SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, according to subclause 11.5.2.
11.6.4 Termination
The Sender shall terminate the SDU discard with explicit signalling procedure if one of the following criteria is fulfilled:
– a STATUS PDU/piggybacked STATUS PDU containing an MRW_ACK SUFI is received, and the SN_ACK field in the received MRW_ACK SUFI > the SN_MRWLENGTH field in the transmitted MRW_SUFI, and the N field in the received MRW_ACK SUFI is set equal to "0000";
– a STATUS PDU/piggybacked STATUS PDU containing an MRW_ACK SUFI is received, and the SN_ACK field in the received MRW_ACK SUFI = the SN_MRWLENGTH field in the transmitted MRW_SUFI, and the N field in the received MRW_ACK SUFI is set equal to the NLENGTH field in the transmitted MRW SUFI;
– a STATUS PDU/piggybacked STATUS PDU containing an ACK SUFI is received, and this STATUS PDU/piggybacked STATUS PDU indicates that all AMD PDUs up to and including the AMD PDU with "Sequence Number" equal to (SN_MRWLENGTH field in the transmitted MRW SUFI) – 1 has been received or discarded by the peer entity.
Upon termination of the SDU discard with explicit signalling procedure, the Sender shall:
– stop the timer Timer_MRW;
– update VT(A) and VT(MS) according to the received STATUS PDU/piggybacked STATUS PDU;
The Sender shall not confirm to upper layers the SDUs that are requested to be discarded.
11.6.4a Reached maximum number of attempts
If VT(MRW) = MaxMRW, the Sender shall:
– terminate the SDU discard with explicit signalling procedure;
– stop the timer Timer_MRW if it was started;
– initiate the RLC RESET procedure (see subclause 11.4).
11.6.5 Expiration of timer Timer_MRW
If Timer_MRW expires before the discard procedure is terminated, the Sender shall:
– increment VT(MRW) by one;
– if VT(MRW)<MaxMRW:
– set the MRW SUFI as previously transmitted (even if additional SDUs were discarded in the mean-time);
– include the MRW SUFI in a new status report (if other SUFIs are included, their contents shall be updated);
– transmit the status report by either including it in a STATUS PDU or piggybacked in an AMD PDU;
– restart Timer_MRW for this discard procedure according to the description in subclause 9.5.
– else (if VT(MRW) = MaxMRW):
– perform the actions specified in subclause 11.6.4a.
11.6.6 Abnormal cases
11.6.6.1 Reception of obsolete/corrupted MRW SUFI by the Receiver
If the received MRW SUFI contains outdated information about the reception window (reception window already moved further than MRW SUFI is indicating), the Receiver shall:
– discard the MRW SUFI;
– set the SN_ACK field in the MRW_ACK SUFI to the current value of VR(R);
– set the N field in the MRW_ACK SUFI to "0000";
– include the MRW_ACK SUFI in the next STATUS PDU/piggybacked STATUS PDU to be transmitted, according to subclause 11.5.2.
11.6.6.2 Void
11.6.6.3 Reception of obsolete/corrupted MRW_ACK SUFI by the Sender
The Sender shall discard the received MRW_ACK SUFI if one of the following cases occurs:
– no ongoing SDU discard with explicit signalling procedure; or
– the SN_ACK field in the received MRW_ACK SUFI < the SN_MRWLENGTH field in the transmitted MRW SUFI; or
– the SN_ACK field in the received MRW_ACK SUFI = the SN_MRWLENGTH field in the transmitted MRW SUFI, and the N field in the received MRW_ACK SUFI is not equal to the NLENGTH field in the transmitted MRW SUFI; or
– the SN_ACK field in the received MRW_ACK SUFI > the SN_MRWLENGTH field in the transmitted MRW SUFI, and the N field in the received MRW_ACK SUFI is not equal to "0000".
11.7 Void
11.8 Void
Annex A (informative):
Change history
|
Change history |
|||||||
|---|---|---|---|---|---|---|---|
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
10/1999 |
RP-05 |
RP-99465 |
– |
Approved at TSG-RAN #5 and placed under Change Control |
3.0.0 |
||
|
12/1999 |
RP-06 |
RP-99641 |
001 |
RLC: Editorial corrections |
3.1.0 |
||
|
RP-06 |
RP-99641 |
002 |
1 |
Editorial changes on RLC protocol specification |
3.1.0 |
||
|
RP-06 |
RP-99643 |
003 |
1 |
MRW procedure |
3.1.0 |
||
|
RP-06 |
RP-99643 |
004 |
SDU Discard Functionality |
3.1.0 |
|||
|
RP-06 |
RP-99643 |
005 |
2 |
Change in RLC control PDU format |
3.1.0 |
||
|
RP-06 |
RP-99642 |
006 |
1 |
Editorial corrections regarding CTCH |
3.1.0 |
||
|
RP-06 |
RP-99641 |
007 |
Updated RLC SDL |
3.1.0 |
|||
|
RP-06 |
RP-99642 |
011 |
RLC Editorial Changes |
3.1.0 |
|||
|
RP-06 |
RP-99642 |
013 |
Editorial Modification on RLC specification |
3.1.0 |
|||
|
RP-06 |
RP-99641 |
014 |
Editorial changes |
3.1.0 |
|||
|
RP-06 |
RP-99642 |
015 |
Change to one PU in a AMD PDU |
3.1.0 |
|||
|
RP-06 |
RP-99643 |
016 |
1 |
Introduction of RLC suspend state |
3.1.0 |
||
|
RP-06 |
RP-99641 |
017 |
1 |
RLC editorial corrections |
3.1.0 |
||
|
01/2000 |
– |
– |
– |
Editorial corrections in title and Annex A (SDL) |
3.1.1 |
||
|
– |
– |
– |
Correction of persistent error regarding SDL in Table of Contents |
3.1.2 |
|||
|
03/2000 |
RP-07 |
RP-000040 |
018 |
1 |
RLC editorial changes |
3.2.0 |
|
|
RP-07 |
RP-000040 |
021 |
1 |
Corrections to RLC |
3.2.0 |
||
|
RP-07 |
RP-000040 |
025 |
2 |
Corrections to RLC |
3.2.0 |
||
|
RP-07 |
RP-000040 |
026 |
1 |
STATUS PDUs |
3.2.0 |
||
|
RP-07 |
RP-000040 |
027 |
1 |
Clarification of RLC AMD Model |
3.2.0 |
||
|
RP-07 |
RP-000040 |
028 |
Corrections to Timer_discard procedures |
3.2.0 |
|||
|
RP-07 |
RP-000040 |
029 |
1 |
Segmentation of RLC SDUs |
3.2.0 |
||
|
RP-07 |
RP-000040 |
030 |
2 |
Modification of SDU discard to support virtual PDCP sequence numbers |
3.2.0 |
||
|
RP-07 |
RP-000040 |
031 |
Removal of SCCH |
3.2.0 |
|||
|
RP-07 |
RP-000040 |
032 |
Updated RLC SDL |
3.2.0 |
|||
|
RP-07 |
RP-000040 |
033 |
1 |
RLC Editorial Changes |
3.2.0 |
||
|
RP-07 |
RP-000040 |
034 |
Order of bit transmission for RLC PDUs |
3.2.0 |
|||
|
06/2000 |
RP-08 |
RP-000220 |
038 |
Corrections to RLC |
3.3.0 |
||
|
RP-08 |
RP-000220 |
039 |
Correction to the description of the MRW SUFI fields |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
040 |
1 |
Editorial corrections to length indicators and local suspend rate |
3.3.0 |
||
|
RP-08 |
RP-000220 |
041 |
4 |
Clarification of the RESET PDU |
3.3.0 |
||
|
RP-08 |
RP-000220 |
043 |
1 |
Clarification of RLC/MAC interaction |
3.3.0 |
||
|
RP-08 |
RP-000220 |
044 |
2 |
General RLC corrections |
3.3.0 |
||
|
RP-08 |
RP-000220 |
045 |
Clarification of RLC Transparent Mode operation |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
048 |
Editorial corrections to abbreviations, SCCH, BCCH |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
052 |
Updated RLC SDL |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
053 |
Correction to RLC |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
055 |
RLC Logical Channel mapping |
3.3.0 |
|||
|
RP-08 |
RP-000220 |
057 |
Correction of EPC timer mechanism |
3.3.0 |
|||
|
09/2000 |
RP-09 |
RP-000358 |
059 |
1 |
State variables after window change |
3.4.0 |
|
|
RP-09 |
RP-000358 |
060 |
4 |
SDU discard |
3.4.0 |
||
|
RP-09 |
RP-000358 |
061 |
5 |
General RLC corrections |
3.4.0 |
||
|
RP-09 |
RP-000358 |
066 |
Editorial changes to RLC |
3.4.0 |
|||
|
RP-09 |
RP-000358 |
067 |
4 |
Correction to RLC window size range |
3.4.0 |
||
|
RP-09 |
RP-000358 |
068 |
2 |
Window based polling |
3.4.0 |
||
|
RP-09 |
RP-000358 |
070 |
2 |
General corrections to RLC |
3.4.0 |
||
|
RP-09 |
RP-000358 |
071 |
State Transition in RLC Acknowledged Mode |
3.4.0 |
|||
|
RP-09 |
RP-000358 |
073 |
Clarification of the Length Indicators |
3.4.0 |
|||
|
RP-09 |
RP-000358 |
076 |
1 |
RLC corrections |
3.4.0 |
||
|
RP-09 |
RP-000358 |
077 |
1 |
Corrections to reset procedure and length indicator definitions |
3.4.0 |
||
|
RP-09 |
RP-000358 |
078 |
RLC Modes for SHCCH |
3.4.0 |
|||
|
RP-09 |
RP-000358 |
079 |
CCCH in UM RLC |
3.4.0 |
|||
|
12/2000 |
RP-10 |
RP-000568 |
080 |
1 |
Length Indicator and PDU formats |
3.5.0 |
|
|
RP-10 |
RP-000568 |
083 |
3 |
Clarification to the Estimated PDU Counter |
3.5.0 |
||
|
RP-10 |
RP-000568 |
084 |
2 |
Model of UM and AM entities |
3.5.0 |
||
|
RP-10 |
RP-000568 |
085 |
1 |
General RLC corrections |
3.5.0 |
||
|
RP-10 |
RP-000568 |
086 |
1 |
General RLC corrections |
3.5.0 |
||
|
RP-10 |
RP-000568 |
087 |
5 |
RLC timers |
3.5.0 |
||
|
RP-10 |
RP-000568 |
088 |
1 |
Reset procedure |
3.5.0 |
||
|
RP-10 |
RP-000568 |
089 |
1 |
Editorial corrections to RLC |
3.5.0 |
||
|
RP-10 |
RP-000568 |
090 |
2 |
RLC UM protocol |
3.5.0 |
||
|
RP-10 |
RP-000568 |
092 |
2 |
Clarification to window size parameters, MRW SUFI and window based polling |
3.5.0 |
||
|
RP-10 |
RP-000568 |
093 |
3 |
General RLC Corrections |
3.5.0 |
||
|
RP-10 |
RP-000568 |
094 |
1 |
RLC Reset handling |
3.5.0 |
||
|
RP-10 |
RP-000568 |
095 |
Inclusion of stage 3 for ciphering |
3.5.0 |
|||
|
03/2001 |
RP-11 |
RP-010026 |
097 |
1 |
Clarification on LIST SUFI and RLIST SUFI |
3.6.0 |
|
|
RP-11 |
RP-010026 |
098 |
1 |
Corrections and clarifications for SDU discard without explicit signalling |
3.6.0 |
||
|
RP-11 |
RP-010026 |
099 |
1 |
Tr mode operation |
3.6.0 |
||
|
RP-11 |
RP-010026 |
100 |
1 |
Timer based discard with explicit signalling |
3.6.0 |
||
|
RP-11 |
RP-010026 |
101 |
Annex updates |
3.6.0 |
|||
|
RP-11 |
RP-010026 |
103 |
Clarification on MRW SUFI and SDU discard procedure |
3.6.0 |
|||
|
RP-11 |
RP-010026 |
104 |
1 |
General clarification on SN arithmetic comparison |
3.6.0 |
||
|
RP-11 |
RP-010026 |
105 |
2 |
General clarification on RLC header and PDU header |
3.6.0 |
||
|
RP-11 |
RP-010026 |
106 |
1 |
Clarification on the primitives between RLC and higher layers |
3.6.0 |
||
|
RP-11 |
RP-010026 |
107 |
1 |
Clarification on the model of AM entity |
3.6.0 |
||
|
RP-11 |
RP-010026 |
109 |
2 |
Clarification on UMD transfer procedure |
3.6.0 |
||
|
RP-11 |
RP-010026 |
110 |
1 |
RLC status transmission in CELL_PCH and URA_PCH |
3.6.0 |
||
|
RP-11 |
RP-010026 |
111 |
Re-establishment description |
3.6.0 |
|||
|
RP-11 |
RP-010026 |
112 |
1 |
Clarifications on the RESET and RESET ACK PDU sizes |
3.6.0 |
||
|
RP-11 |
RP-010026 |
113 |
1 |
Editorial corrections and clarifications |
3.6.0 |
||
|
RP-11 |
RP-010026 |
114 |
1 |
Clarifications on the RLC-AM-DATA-Conf primitive |
3.6.0 |
||
|
RP-11 |
RP-010026 |
116 |
Removal of the payload unit concept |
3.6.0 |
|||
|
RP-11 |
RP-010026 |
118 |
2 |
Padding Blocks and TFC selection pre-empting |
3.6.0 |
||
|
RP-11 |
– |
– |
Upgrade to Release 4 – no technical change |
4.0.0 |
|||
|
06/2001 |
RP-12 |
RP-010309 |
120 |
Clarification on ACK SUFI |
4.1.0 |
||
|
RP-12 |
RP-010309 |
122 |
MRW SUFI clarification and enhancement |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
124 |
Clarification on AM states |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
126 |
Clarification on HFN update in RESET procedure |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
128 |
Clarification of RLC Discard |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
130 |
Removal of reference to RRC |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
132 |
Clarification in the LI Parameters section |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
136 |
Cleanup of RLC services and functions |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
138 |
Clarification on RLC re-establishment |
4.1.0 |
|||
|
RP-12 |
RP-010309 |
140 |
Corrections and clarifications to the LIST and RLIST SUFI types |
4.1.0 |
|||
|
09/2001 |
RP-13 |
RP-010542 |
142 |
General clarifications |
4.2.0 |
||
|
RP-13 |
RP-010542 |
150 |
Correction to RLC state variables |
4.2.0 |
|||
|
12/2001 |
RP-14 |
RP-010761 |
152 |
General clarifications |
4.3.0 |
||
|
RP-14 |
RP-010761 |
156 |
Send state variable for Timer_Poll and window based polling |
4.3.0 |
|||
|
RP-14 |
RP-010761 |
158 |
Unexpected data interruption during transmission scheduling |
4.3.0 |
|||
|
RP-14 |
RP-010761 |
162 |
UE-ID Type Indicator |
4.3.0 |
|||
|
RP-14 |
RP-010761 |
164 |
Removal of obsolete Send MRW option |
4.3.0 |
|||
|
RP-14 |
RP-010771 |
160 |
Content of retransmitted RESET ACK PDU |
4.3.0 |
|||
|
RP-14 |
RP-010771 |
166 |
Usage of UM RLC Special Length Indicator |
4.3.0 |
|||
|
RP-14 |
RP-010771 |
170 |
Indication of SDU transmission result |
4.3.0 |
|||
|
03/2002 |
RP-15 |
RP-020068 |
172 |
Clarification on MRW SUFI and SDU discard with explicit signalling procedure |
4.4.0 |
||
|
RP-15 |
RP-020068 |
176 |
SDU discard termination |
4.4.0 |
|||
|
RP-15 |
RP-020068 |
180 |
Initial value of VT(US) |
4.4.0 |
|||
|
RP-15 |
– |
– |
Upgrade to Release 5 – no technical change |
5.0.0 |
|||
|
06/2002 |
RP-16 |
RP-020327 |
186 |
Handling abnormal UMD PDUs and AMD PDUs |
5.1.0 |
||
|
RP-16 |
RP-020327 |
189 |
Clarification of the use of Length Indicators |
5.1.0 |
|||
|
RP-16 |
RP-020327 |
192 |
1 |
Correction to MaxDAT, MaxRST and MaxMRW |
5.1.0 |
||
|
RP-16 |
RP-020327 |
195 |
Clarification on polling functions |
5.1.0 |
|||
|
09/2002 |
RP-17 |
RP-020539 |
198 |
Correction to the behaviour after expiration of Timer_MRW during the SDU discard with explicit signalling procedure |
5.2.0 |
||
|
RP-17 |
RP-020539 |
201 |
Corrections to RLC retransmissions |
5.2.0 |
|||
|
RP-17 |
RP-020637 |
204 |
1 |
Corrections to RLC RESET procedure and Length Indicators |
5.2.0 |
||
|
RP-17 |
RP-020539 |
207 |
Corrections on handling of timers during a RLC reset or re-establishment |
5.2.0 |
|||
|
RP-17 |
RP-020551 |
209 |
Corrections on indication of SDU transmission result |
5.2.0 |
|||
|
12/2002 |
RP-18 |
RP-020719 |
212 |
RB id in ciphering |
5.3.0 |
||
|
RP-18 |
RP-020862 |
213 |
Generation of RLC Status Reports to coordinate with MAC-hs reset |
5.3.0 |
|||
|
03/2003 |
RP-19 |
RP-030101 |
216 |
Correction to VT(MRW) definition |
5.4.0 |
||
|
RP-19 |
RP-030116 |
217 |
Enhancement of MRW procedure |
5.4.0 |
|||
|
06/2003 |
RP-20 |
RP-030292 |
220 |
2 |
Handling of erroneous PDUs |
5.5.0 |
|
|
RP-20 |
RP-030292 |
225 |
Setting of the “Polling bit” in the “Every Poll_SDU SDU” function |
5.5.0 |
|||
|
RP-20 |
RP-030297 |
222 |
Receiver behaviour when detecting an AMD PDU duplicate |
5.5.0 |
|||
|
RP-20 |
RP-030297 |
227 |
RLC window size reconfigurations |
5.5.0 |
|||
|
09/2003 |
RP-21 |
RP-030483 |
230 |
SDU Concatenation Exceptions and SDU Concatenation in AM Mode |
5.6.0 |
||
|
RP-21 |
RP-030483 |
233 |
1 |
Decision of Discarded SDUs from Discarded PDUs |
5.6.0 |
||
|
RP-21 |
RP-030483 |
236 |
1 |
RLC Reset Triggering and Update of VT(RST) |
5.6.0 |
||
|
RP-21 |
RP-030483 |
239 |
correction to the ‘SDU discard with explicit signalling’ procedure |
5.6.0 |
|||
|
RP-21 |
RP-030478 |
242 |
Elimination of EPC mechanism |
5.6.0 |
|||
|
RP-21 |
RP-030483 |
245 |
Correction of MRW and RESET timers in RLC |
5.6.0 |
|||
|
RP-21 |
RP-030490 |
247 |
Reconfiguration of RLC window size |
5.6.0 |
|||
|
12-2003 |
RP-22 |
RP-030616 |
250 |
BITMAP and status report content |
5.7.0 |
||
|
RP-22 |
RP-030620 |
252 |
Indication of discarded SDU in RLC Reset and Re-establishment |
5.7.0 |
|||
|
RP-22 |
– |
– |
Upgrade to Release 6 – no technical change |
6.0.0 |
|||
|
06-2004 |
RP-24 |
RP-040224 |
258 |
DL RLC Size handling |
6.1.0 |
||
|
12-2004 |
RP-26 |
RP-040504 |
262 |
1 |
Correction of MRW SUFI content setting rule |
6.2.0 |
|
|
RP-26 |
RP-040504 |
264 |
1 |
Correction of Poll Prohibit function |
6.2.0 |
||
|
RP-26 |
RP-040490 |
265 |
1 |
Inclusion of out of sequence SDU delivery |
6.2.0 |
||
|
RP-26 |
RP-040490 |
266 |
Addition of MBMS Logical Channels and UM functionality for ‘duplicate avoidance and reordering’ |
6.2.0 |
|||
|
03-2005 |
RP-27 |
RP-050113 |
260 |
1 |
Correction of MRW termination on reception of ACK SUFI |
6.3.0 |
|
|
RP-27 |
RP-050113 |
265 |
Correction to RLC Re-establishment |
6.3.0 |
|||
|
RP-27 |
RP-050113 |
267 |
CRCLC-Config-Req in LOCAL_SUSPEND State |
6.3.0 |
|||
|
RP-27 |
RP-050113 |
268 |
Protocol error detection and recovery |
6.3.0 |
|||
|
RP-27 |
RP-050068 |
270 |
Removal of the EPC mechanism |
6.3.0 |
|||
|
RP-27 |
RP-050082 |
271 |
Inclusion of transmitter constraints |
6.3.0 |
|||
|
06-2005 |
RP-28 |
RP-050319 |
0272 |
Correction on actions taken Upon reception of an duplicated AMD PDU within the reception window |
6.4.0 |
||
|
RP-28 |
RP-050315 |
0273 |
Clarification on a Transmitter Constraint |
6.4.0 |
|||
|
RP-28 |
RP-050319 |
0274 |
Reconfiguration of RLC parameters by upper layers may lead to Logic inconsistency of state variable VrH |
6.4.0 |
|||
|
RP-28 |
RP-050302 |
0276 |
Erroneous Sequence Number definition |
6.4.0 |
|||
|
RP-28 |
RP-050319 |
0277 |
Selecting a PDU to transmit a poll |
6.4.0 |
|||
|
RP-28 |
RP-050319 |
0278 |
Support for out-of-sequence PDUs in RLC-UM |
6.4.0 |
|||
|
RP-28 |
RP-050315 |
0279 |
1 |
Clarification of the "Out of sequence SDU delivery" |
6.4.0 |
||
|
RP-28 |
RP-050317 |
0280 |
RLC LI Optimization for VoIP |
6.4.0 |
|||
|
RP-28 |
RP-050315 |
0281 |
Correction to Out Of Sequence Delivery |
6.4.0 |
|||
|
RP-28 |
RP-050315 |
0282 |
Clarification on operations when UE MCCH RLC entity is re-established and OSD_Window_Size is reconfigured |
6.4.0 |
|||
|
09-2005 |
RP-29 |
RP-050463 |
0284 |
Single Sided RLC Re-establishment |
6.5.0 |
||
|
RP-29 |
RP-050481 |
0285 |
Removal RLC-SDU alignment capability |
6.5.0 |
|||
|
RP-29 |
RP-050468 |
0286 |
Arithmetic comparison for DAR function and VR(US) after MBMS being included |
6.5.0 |
|||
|
RP-29 |
RP-050468 |
0287 |
Clarification on DAR window reconfiguration |
6.5.0 |
|||
|
RP-29 |
RP-050468 |
0288 |
Clarification on reception of UMD PDU when OSD function is configured |
6.5.0 |
|||
|
12-2005 |
RP-30 |
RP-050784 |
0290 |
Correction on transmission of AMD PDU |
6.6.0 |
||
|
RP-30 |
RP-050788 |
0293 |
Initiation of state variable VR(UOH) |
6.6.0 |
|||
|
RP-30 |
RP-050788 |
0294 |
Clarification on reception of UMD PDU when OSD function is configured |
6.6.0 |
|||
|
RP-30 |
RP-050797 |
0296 |
Corrections to RLC re-establishment |
6.6.0 |
|||
|
RP-30 |
RP-050802 |
0297 |
1 |
RLC UMD header optimisation for RT services over HSDPA/HSUPA |
6.6.0 |
||
|
03-2006 |
RP-31 |
RP-060090 |
0292 |
2 |
Correction to RLC Re-establishment Procedure |
6.7.0 |
|
|
RP-31 |
RP-060090 |
0298 |
Correction to RLC reset procedure |
6.7.0 |
|||
|
RP-31 |
RP-060094 |
0299 |
Introducing missing "and" to the RLC UMD operation with LI optimisation |
6.7.0 |
|||
|
RP-31 |
– |
– |
Upgrade to the Release 7 – no technical change |
7.0.0 |
|||
|
06/2006 |
RP-32 |
RP-060363 |
0301 |
1 |
Clarification on abortion of RLC Reset procedure |
7.1.0 |
|
|
RP-32 |
RP-060363 |
0303 |
RLC SDU Discard during re-establishment |
7.1.0 |
|||
|
09/2006 |
RP-33 |
RP-060575 |
0305 |
AMD PDU discard |
7.2.0 |
||
|
06/2007 |
RP-36 |
RP-070407 |
0306 |
1 |
Removing an incomplete optimization for RLC operations during HSDPA cell change |
7.3.0 |
|
|
RP-36 |
RP-070407 |
0307 |
– |
Correction to Out of Sequence Reception function |
7.3.0 |
||
|
RP-36 |
RP-070407 |
0308 |
– |
DAR over CCCH |
7.3.0 |
||
|
RP-36 |
RP-070404 |
0309 |
2 |
Introduction of Improved L2 support for high data rates |
7.3.0 |
||
|
RP-36 |
RP-070416 |
0311 |
– |
Corrections on modulus base in UM in RLC |
7.3.0 |
||
|
RP-36 |
RP-070407 |
0312 |
– |
Using special value of HE field to indicate end of an SDU for RLC AM |
7.3.0 |
||
|
09/2007 |
RP-37 |
RP-070626 |
0313 |
Correction on POLL SUFI |
7.4.0 |
||
|
RP-37 |
RP-070626 |
0314 |
Special HE value setting |
7.4.0 |
|||
|
12/2007 |
RP-38 |
RP-070905 |
0315 |
Correction to Control Information transmission with two logical channels |
7.5.0 |
||
|
RP-38 |
RP-070910 |
0316 |
Introduction of CS Voice over HSPA |
8.0.0 |
|||
|
03/2008 |
RP-39 |
RP-080178 |
0319 |
– |
Correction to Reception of UM RLC |
8.1.0 |
|
|
RP-39 |
RP-080191 |
0321 |
– |
Correction to Control Information transmission |
8.1.0 |
||
|
RP-39 |
RP-080191 |
0323 |
– |
Poll SUFI and Status Reporting |
8.1.0 |
||
|
RP-39 |
RP-080202 |
0324 |
– |
Introducing flexible RLC PDU size in the uplink |
8.1.0 |
||
|
RP-39 |
RP-080190 |
0326 |
– |
Correction to the RLC RESET and RESET ACK PDU with flexible RLC PDU size |
8.1.0 |
||
|
06/2008 |
RP-40 |
RP-080403 |
0328 |
1 |
Correction on UM model depiction |
8.2.0 |
|
|
RP-40 |
RP-080391 |
0330 |
1 |
Clarification on DAR Operation |
8.2.0 |
||
|
RP-40 |
RP-080405 |
0331 |
– |
CS-HSPA UL Segmentation |
8.2.0 |
||
|
RP-40 |
RP-080395 |
0333 |
3 |
Removal of UTRAN behaviour |
8.2.0 |
||
|
RP-40 |
RP-080414 |
0334 |
– |
Correction to transmitting AM RLC entity |
8.2.0 |
||
|
RP-40 |
RP-080414 |
0335 |
1 |
Removal of Redundant Description in Transmitting Side |
8.2.0 |
||
|
RP-40 |
RP-080390 |
0338 |
– |
Non-applicability of ciphering for MCCH, MSCH and MTCH |
8.2.0 |
||
|
RP-40 |
RP-080395 |
0343 |
– |
Maximum RLC PDU size |
8.2.0 |
||
|
RP-40 |
RP-080414 |
0344 |
1 |
RLC PDU size adaptation |
8.2.0 |
||
|
09/2008 |
RP-41 |
RP-080685 |
0349 |
Correction to definition of N_LENGTH |
8.3.0 |
||
|
03/2009 |
RP-43 |
RP-090117 |
0353 |
– |
Correction for VR(UM) |
8.4.0 |
|
|
RP-43 |
RP-090140 |
0354 |
– |
Concatenation/segmentation in case SN_Delivery parameter is configured |
8.4.0 |
||
|
RP-43 |
RP-090138 |
0356 |
1 |
Clarification for the description of transmitting UM RLC entity |
8.4.0 |
||
|
RP-43 |
RP-090138 |
0357 |
– |
Correction to RLC text for MAC i/is |
8.4.0 |
||
|
RP-43 |
RP-090151 |
0358 |
– |
Removal of DCCH logical channel mapped on RLC TM entity |
8.4.0 |
||
|
06/2009 |
RP-44 |
RP-090519 |
0359 |
– |
Submission of UMD PDU when SN_Delivery is configured |
8.5.0 |
|
|
RP-44 |
RP-090505 |
0364 |
– |
Removal of references to MAC-hs reset |
8.5.0 |
||
|
09/2009 |
RP-45 |
RP-090917 |
0366 |
– |
Clarification on minimum PDU size |
8.6.0 |
|
|
RP-45 |
RP-090909 |
0368 |
– |
Clarification to LI setting after Timer_Discard expiry when alternative e-bit is used |
8.6.0 |
||
|
12/2009 |
RP-46 |
RP-091329 |
0369 |
– |
Introduction of POLL_SUFI in UL data transfer |
8.7.0 |
|
|
RP-46 |
RP-091336 |
0373 |
– |
Partial radio awareness for DC-HSUPA capable UEs |
9.0.0 |
||
|
03/2010 |
RP-47 |
RP-100286 |
0375 |
– |
RLC recovery with uplink POLL_SUFI(R9) |
9.1.0 |
|
|
06/2010 |
RP-48 |
RP-100537 |
0379 |
2 |
Correction of Poll SUFI handling for Improved L2 Uplink |
9.2.0 |
|
|
12/2010 |
RP-50 |
RP-101365 |
0388 |
– |
Introduction of LCR TDD MC-HSUPA in 25.322 |
10.0.0 |
|
|
06/2011 |
RP-52 |
RP-110771 |
0391 |
2 |
Accept RLC PDUs with special value HE field if it’s supported |
10.1.0 |
|
|
09/2012 |
RP-57 |
RP-121369 |
0403 |
– |
Introduction of Multiflow in TS 25.322 |
11.0.0 |
|
|
12/2012 |
RP-58 |
RP-121943 |
0404 |
– |
Introduction of further Multiflow agreements in TS 25.322 |
11.1.0 |
|
|
03/2013 |
RP-59 |
RP-130239 |
0405 |
– |
Clarification on RLC Status Report prohibit functions |
11.2.0 |
|
|
09/2014 |
RP-65 |
– |
– |
– |
– |
Upgrade to the Release 12 – no technical change |
12.0.0 |
|
12/2015 |
RP-70 |
– |
– |
– |
– |
Upgrade to the Release 13 – no technical change |
13.0.0 |
|
03/2017 |
RP-75 |
– |
– |
– |
– |
Upgrade to Release 14 – no technical change |
14.0.0 |
|
06/2018 |
RP-80 |
– |
– |
– |
– |
Upgrade to Release 15 – no technical change |
15.0.0 |
|
2020-07 |
RP-88e |
– |
– |
– |
– |
Upgrade to Rel-16 version without technical change |
16.0.0 |
|
2022-03 |
RP-95e |
– |
– |
– |
– |
Upgrade to Rel-17 version without technical change |
17.0.0 |