9.7 Specific functions
25.3223GPPRadio Link Control (RLC) protocol specificationRelease 17TS
The functions defined in this subclause are normative.
9.7.1 Polling function for acknowledged mode
The Polling function is used by the Sender to request the peer RLC entity for a status report. The "Polling bit" in the AMD PDU or the POLL SUFI indicate the poll request. There are several triggers for initiating the Polling function. Which of the triggers shall be used is configured by upper layers for each RLC entity. The following triggers can be configured:
1) Last PDU in buffer.
When an AMD PDU to be transmitted for the first time is submitted to lower layer, the Sender shall:
– if the AMD PDU is the last AMD PDU scheduled for transmission according to subclause 11.3.2 (i.e. no data received from upper layer remains to be segmented into AMD PDUs); or
– if the AMD PDU is the last AMD PDU that is allowed to transmit according to subclause 11.3.2.2:
– trigger a poll for this AMD PDU.
2) Last PDU in Retransmission buffer.
When a retransmitted AMD PDU is submitted to lower layer, the Sender shall:
– if the AMD PDU is the last AMD PDU scheduled for retransmission according to subclause 11.3.2; or
– if the AMD PDU is the last of the AMD PDUs scheduled for retransmission that are allowed to transmit according to subclause 11.3.2.2:
– trigger a poll for this AMD PDU.
3) Poll timer.
The timer Timer_Poll is started and stopped according to subclause 9.5 a). When the timer Timer_Poll expires the Sender triggers the Polling function.
4) Every Poll_PDU PDU.
The Sender triggers the Polling function for every Poll_PDU PDU. Both retransmitted and new AMD PDUs shall be counted.
5) Every Poll_SDU SDU.
The Sender triggers the Polling function for every Poll_SDU SDU. The poll shall be triggered for the first transmission of the AMD PDU that contains the last segment of an RLC SDU (indicated either by the "Length Indicator" indicating the end of the SDU or by the special value of the HE field).
6) Window based.
The Sender triggers the Polling function when the condition described in subclause 9.6 d) ("Poll_Window") is fulfilled.
7) Timer based.
The Sender triggers the Polling function periodically.
UTRAN should configure RLC to avoid deadlock situations.
The Poll Prohibit function is used by the Sender to delay the initiation of the Polling function. Usage of the Poll Prohibit function is configured by upper layers. The Poll Prohibit function consists of starting the timer Timer_Poll_Prohibit according to subclause 9.5 b) and delaying the Polling function according to the following rules:
When the Polling function is triggered, the Sender shall:
– if polling is not prohibited (see subclause 9.5 b)); and
– if there is one or more AMD PDUs to be transmitted or there are AMD PDUs not acknowledged by the Receiver:
– initiate the Polling function by setting the polling bit according to subclause 11.3.2.1.1.
– otherwise (if there is no PDU to be transmitted and all PDUs have already been acknowledged):
– not initiate the Polling function.
Upon expiry of the timer Timer_Poll_Prohibit, the Sender shall:
– if the Polling function was triggered at least once while the timer Timer_Poll_Prohibit was active; and
– if there is one or more AMD PDUs to be transmitted or there are AMD PDUs not acknowledged by the Receiver:
– initiate the Polling function once by setting the polling bit according to subclause 11.3.2.1.1.
– otherwise (if there is no PDU to be transmitted and all PDUs have already been acknowledged):
– not initiate the Polling function.
NOTE 1: In downlink, UTRAN can initiate the Polling function by assembling a POLL SUFI according to subclause 9.2.2.11.9 when "flexible RLC PDU size" in downlink is configured.
NOTE 2: 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.
9.7.2 STATUS transmission for acknowledged mode
The Receiver transmits status reports to the Sender in order to inform the Sender about which AMD PDUs have been received and not received. Each status report consists of one or several STATUS PDUs. The Receiver shall trigger the transmission of a status report when receiving a poll request. Additionally, the following triggers for transmission of status reports are configurable by upper layers:
1) Detection of missing PDU(s).
If the Receiver detects one or several missing AMD PDUs it shall trigger the transmission of a status report to the Sender.
2) Timer based status report transfer.
The Receiver triggers the transmission of a status report to the Sender periodically. The timer Timer_Status_Periodic controls the time period according to subclause 9.5 g). When "Periodical Status blocking" is configured by upper layers, the trigger shall not be active.
3) Void
There are several functions that can prohibit the Receiver from sending a status report containing any of the SUFIs LIST, BITMAP, RLIST or ACK. Status reports containing other SUFIs are not prohibited. Upper layers control which functions should be used for each RLC entity. If any of the following functions is used the transmission of the status report shall be delayed, even if any of the triggering conditions above are fulfilled:
1) STATUS prohibit.
The timer Timer_Status_Prohibit is started according to subclause 9.5 f). The Receiver is not allowed to transmit a status report while acknowledgement is prohibited (see subclause 9.5 f)). If a status report was triggered during this time, the status report is transmitted after the timer Timer_Status_Prohibit has expired, as described below.
2) Void
3) Timer_Reordering
The timer Timer_Reordering is started according to subclause 11.3.3. The receiver is not allowed to transmit a status report while the timer is running. If a status report was triggered during this time, the status report is transmitted after the timer Timer_Reordering has expired, as described below.
When a status report is triggered the Receiver shall:
– if transmission of status reports is not prohibited by any of the functions "STATUS prohibit" or "Timer_Reordering":
– assemble and transmit the status report to the Sender, as specified in subclauses 11.5.2.2 and 11.5.2.3.
– otherwise (if the status report is prohibited by at least one of the functions "STATUS prohibit"):
– if MRW, MRW_ACK, WINDOW or POLL SUFIs are required in the status report:
– send a status report immediately excluding ACK, LIST, BITMAP, and RLIST SUFIs;
– if ACK, LIST, BITMAP, or RLIST SUFIs are required in the status report:
– delay sending these SUFIs until the prohibit function terminates.
Upon expiry of the timer Timer_Status_Prohibit, the Receiver shall:
– if at least one status report was triggered during the time the transmission of a status reports was prohibited that could not be transmitted due to prohibition; and
– if transmission of a status reports is no longer prohibited by any of the functions "STATUS prohibit" or "Timer_Reordering":
– transmit one status report to the Sender, using the procedure described in subclause 11.5.2.3.
Upon expiry of the timer Timer_Reordering, the Receiver shall:
– if at least one status report was triggered during the time the transmission of a status reports was prohibited that could not be transmitted due to prohibition; and
– if transmission of a status reports is no longer prohibited by any of the functions "STATUS prohibit" or "Timer_Reordering":
– update VR(MS) to the SN of the first AMD PDU with SN >= VR(X) which has not been received;
– transmit one status report to the Sender, using the procedure described in subclause 11.5.2.3.
– if VR(H) > VR(MS):
– start Timer_Reordering;
– set VR(X) to VR(H).
9.7.3 SDU discard function for acknowledged, unacknowledged, and transparent mode
The SDU discard function is used by the Sender to discharge RLC PDUs from the RLC PDU buffer, when the transmission of the RLC PDUs does not succeed for a period of time or for a number of transmissions. The SDU discard function allows to avoid buffer overflow. There are several alternative operation modes of the RLC SDU discard function. Upper layers control, which discard function shall be used for each RLC entity.
The following is a list of operation modes for the RLC SDU discard function, which are described in detail in the subsequent subclauses.
Table 9.2: List of criteria that control when to perform SDU discard
|
Operation mode |
Presence |
|
Timer based discard, with explicit signalling |
Network controlled |
|
Timer based discard, without explicit signalling |
Network controlled |
|
SDU discard after MaxDAT number of transmissions |
Network controlled |
|
No_discard after MaxDAT number of transmissions |
Network controlled |
9.7.3.1 Timer based discard, with explicit signalling
This alternative is only applicable to RLC entities operating in acknowledged mode. It uses a timer based triggering of SDU discard (Timer_Discard). This makes the SDU discard function insensitive to variations in the channel rate and provides means for exact definition of maximum delay. However, the SDU loss rate of the connection is increased as SDUs are discarded.
For every SDU received from upper layers, the Sender shall:
– start a timer Timer_Discard.
When the timer Timer_Discard of a SDU expires, the Sender shall:
– discard the SDU;
– if "Send MRW" is configured, or one or more segments of the discarded SDU were submitted to the lower layer:
– utilise explicit signalling to inform the Receiver according to subclause 11.6.
NOTE: The support of the configuration "Send MRW" and the functionality connected with this configuration is implementation dependent.
9.7.3.2 Timer based discard, without explicit signalling
This alternative is only applicable to RLC entities operating in unacknowledged or transparent mode. It uses the same timer based trigger for SDU discard (Timer_Discard) as the one described in the subclause 9.7.3.1. The difference is that this discard method does not use any peer-to-peer signalling.
For every SDU received from upper layers, the Sender shall:
– start timer monitoring of the transmission time of the SDU.
When the transmission time exceeds the configured value for a SDU, the Sender shall:
– discard the SDU without explicit signalling (for RLC entities operating in unacknowledged mode apply subclause 11.2.4.3 for updating the state variables).
9.7.3.3 SDU discard after MaxDAT number of transmissions
This alternative uses the number of transmissions as a trigger for SDU discard, and is therefore only applicable for acknowledged mode RLC. This makes the SDU discard function dependent on the channel rate. Also, this variant of the SDU discard function strives to keep the SDU loss rate constant for the connection, on the cost of a variable delay.
If the number of times an AMD PDU is scheduled for transmission reaches MaxDAT, the Sender shall:
– discard all SDUs that have segments or "Length Indicators" indicating the end of the SDUs in the AMD PDU; and
– utilise explicit signalling to inform the Receiver according to clause 11.6.
9.7.3.4 No_discard after MaxDAT number of transmissions
This alternative uses the number of transmissions, and is therefore only applicable for acknowledged mode RLC.
If the number of times an AMD PDU is scheduled for transmission reaches MaxDAT, the Sender shall:
– initiate the RLC Reset procedure (see subclause 11.3.4.4).
9.7.3.5 SDU discard not configured
If SDU discard has not been configured for an unacknowledged mode RLC entity, SDUs in the transmitter shall not be discarded unless the Transmission buffer is full.
When the Transmission buffer in an unacknowledged mode RLC entity is full, the Sender may:
– if segments of the SDU to be discarded have been submitted to lower layer:
– discard the SDU without explicit signalling according to subclause 11.2.4.3.
– otherwise, if no segments of the SDU to be discarded have been submitted to lower layer:
– remove the SDU from the Transmission buffer without utilising any of the discard procedures.
If SDU discard has not been configured for a transparent mode RLC entity, the Sender shall upon reception of new SDUs from upper layer:
– discard all SDUs received from upper layer in previous TTIs that are not yet submitted to lower layer;
– submit the new SDUs in the first possible TTI.
For an acknowledged mode RLC entity, an SDU discard mode is always configured.
9.7.4 Void
9.7.5 Local Suspend function for acknowledged and unacknowledged mode
The upper layers may suspend an RLC entity.
When an RLC entity operating in unacknowledged mode is suspended by upper layers with the parameter N, the RLC entity shall:
– acknowledge the suspend request with a confirmation containing the current value of VT(US);
– not send UMD PDUs with "Sequence Number" SNVT(US)+N.
When an RLC entity operating in acknowledged mode is suspended by upper layers with the parameter N, the RLC entity shall:
– acknowledge the suspend request with a confirmation containing the current value of VT(S);
– not send AMD PDUs with "Sequence Number" SNVT(S)+N.
When an RLC entity operating in unacknowledged mode is resumed by upper layers, the RLC entity shall:
– resume data transfer procedure.
When an RLC entity operating in acknowledged mode is resumed by upper layers, the RLC entity shall:
– if the RLC entity is suspended and a RLC Reset procedure is not ongoing:
– resume data transfer procedure.
– otherwise, if the RLC entity is suspended and a RLC Reset procedure is ongoing:
– remove the suspend constraint;
– resume the RLC reset procedure according to subclause 11.4.
9.7.6 RLC Stop, RLC Continue function for acknowledged and unacknowledged mode
The upper layer may stop an RLC entity.
When an RLC entity is stopped, the RLC timers are not affected.
When a RLC entity is stopped by upper layers, the RLC entity shall:
– not submit any RLC PDUs to lower layer or receive any RLC PDUs;
– delay triggered Polling functions or status transmissions until the RLC entity is continued.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the stop function until the end of the next TTI.
When a RLC entity is continued by upper layers, the RLC entity shall:
– if the RLC entity is stopped:
– continue the data transmission and reception;
– process the triggered Polling functions and status transmissions.
– otherwise, if the RLC is not stopped:
– take no action.
9.7.7 RLC re-establishment function for acknowledged and unacknowledged mode
RLC re-establishment is performed upon request by upper layers.
The RLC re-establishment function is applicable for AM or UM RLC. For UM, the whole RLC entity is re-established. For AM, upper layers may request re-establishment of the whole RLC entity or only the transmitting or receiving side of the RLC entity.
When an UM RLC entity is re-established by upper layers, the RLC entity shall:
– reset the state variables to their initial value;
– set the configurable parameters to their configured value;
– set the hyper frame number (HFN) to the value configured by upper layers;
– if it is a receiving UM RLC entity:
– discard all UMD PDUs.
– stop all timers;
– if it is a transmitting UM RLC entity:
– discard the RLC SDUs for which one or more segments have been submitted to a lower layer;
– if requested:
– inform the upper layers of the discarded SDUs.
– not stop Timer_Discard if the RLC SDU is not discarded.
When the transmitting and/or receiving side of an AM RLC entity is re-established by upper layers, the RLC entity shall:
– if the receiving side of the RLC entity is re-established:
– reset the state variables specified for the receiver in subclause 9.4 to their initial values;
– set the configurable parameters applicable for the receiving side in subclause 9.6 to their configured values;
– set the hyper frame number (HFN) in the receiving side (DL in the UE) to the value configured by upper layers;
– discard the AMD PDUs in the receiving side.
– if only the receiving side of the RLC entity is re-established:
– discard acknowledgement status report, WINDOW SUFI and MRW_ACK SUFI in all STATUS PDUs and piggybacked STATUS PDUs, RESET PDU and RESET ACK PDU (i.e. discard all control PDUs except MRW SUFI and POLL SUFI);
– if an RLC reset procedure is ongoing (i.e. Timer_RST is running):
– stop Timer_RST;
– abort the ongoing RLC reset procedure;
– reset VT(RST);
– restart a new RLC reset procedure after the RLC re-establishment terminates.
– stop Timer_Status_Prohibit;
– for the remaining control PDUs and SUFI that were scheduled for transmission before re-establishment but were not delivered to lower layer:
– assemble the control PDUs and SUFIs that were not discarded into new control PDUs with the configured RLC PDU size;
– schedule the new control PDUs for transmission.
– if the transmitting side of the RLC entity is re-established:
– reset the state variables specified for the sender in subclause 9.4 to their initial values;
– set the configurable parameters applicable for the transmitting side in subclause 9.6 to their configured values;
– set the hyper frame number (HFN) in the transmitting side (UL in the UE) to the value configured by upper layers;
– discard SDUs in the transmitting side that have been completely transmitted (the AMD PDUs containing segments of the SDU and the "Length Indicator" indicating the end of the SDU have been transmitted);
– the UE may also discard partially transmitted SDUs (at least one AMD PDU containing a segment of the SDU has been transmitted);
– segment the SDUs that were not discarded into AMD PDUs with the configured RLC PDU size (that may be different from the size before the re-establishment);
– if only the transmitter side of the RLC entity is re-established:
– discard MRW SUFI and POLL SUFI in all STATUS PDUs and piggybacked STATUS PDUs, RESET PDU and RESET ACK PDU (i.e. discard all control PDUs except acknowledgement status report, WINDOW SUFI and MRW_ACK SUFI);
– for the remaining control PDUs and SUFI that were scheduled for transmission before re-establishment but were not delivered to lower layer:
– assemble the control PDUs and SUFIs that were not discarded into new control PDUs with the configured RLC PDU size;
– schedule the control PDUs for transmission.
– if an RLC reset procedure is ongoing (i.e. Timer_RST is running):
– stop Timer_RST;
– abort the ongoing RLC reset procedure;
– restart a new RLC reset procedure after the RLC re-establishment terminates.
– stop Timer_Poll, Timer_MRW and Timer_Poll_Prohibit.
– if both the transmitter and receiver side of the RLC entity is re-established:
– discard the control PDUs in both transmitting and receiving side and the AMD PDUs in the transmitting side;
– if an RLC reset procedure is ongoing (i.e. Timer_RST is running):
– abort the ongoing RLC reset procedure.
– stop all timers described in subclause 9.5 except Timer_Poll_Periodic and Timer_Status_Periodic, and Timer_Discard for SDUs that have not been discarded.
– if requested:
– inform the upper layers of the discarded SDUs.
NOTE: If the TFC selection exchange has been initiated by sending the RLC Entity Info parameter to MAC, the RLC entity may delay the re-establishment function until the end of the next TTI.
9.7.8 Ciphering for acknowledged and unacknowledged mode
The ciphering function is performed in RLC, according to the following rules if a radio bearer is using a non-transparent RLC mode (AM or UM). The data unit that is ciphered, depends on the transmission mode as described below.
– For RLC UM mode, the ciphering unit is the UMD PDU excluding the first octet, i.e. excluding the UMD PDU header. This is shown below in Figure 9.19.
Figure 9.19: Ciphering unit for a UMD PDU
– For RLC AM mode, the ciphering unit is the AMD PDU excluding the first two octets, i.e. excluding the AMD PDU header. This is shown below in Figure 9.20.
Figure 9.20: Ciphering unit for an AMD PDU
The ciphering algorithm and key to be used are configured by upper layers [8] and the ciphering method shall be applied as specified in [9].
The parameters that are required by RLC for ciphering are defined in [9] and are input to the ciphering algorithm. The parameters required by RLC which are provided by upper layers [8] are listed below:
– RLC AM HFN (Hyper frame number for radio bearers that are mapped onto RLC AM);
– RLC UM HFN (Hyper frame number for radio bearers that are mapped onto RLC UM);
– BEARER (defined as the radio bearer identifier in [9]. It will use the value RB identity –1 as in [8]);
– CK (Ciphering Key).
9.7.9 Reconfiguration of RLC parameters by upper layers
The RLC parameters for an RLC entity may be reconfigured (modified) by upper layers.
When an RLC parameter is reconfigured by the upper layer, the UE shall:
– start using the reconfigured value of the RLC parameter.
If the parameter Configured_Rx_Window_Size is reconfigured:
– the UE shall update the state variable VR(UM), (see clause 9.4);
– the UE shall update the state variable VR(MR), (see clause 9.4);
– for AMD PDUs with "Sequence Number" x such that VR(MR)<=x<VR(H):
– the UE may discard these AMD PDUs; if discarded, the state variable VR(H) should be updated accordingly;
– consider the discarded AMD PDUs as not having been received.
If the parameter Configured_Tx_Window_Size is reconfigured:
– the UE shall set the state variable VT(WS) equal to the Configured_Tx_Window_Size;
– the UE shall update the state variable VT(MS), (see subclause 9.4);
– for AMD PDUs with "Sequence Number" x such that VT(MS)<=x<VT(S):
– the UE shall not discard any AMD PDUs that are not positively acknowledged;
– the UE may discard AMD PDUs that are positively acknowledged.
When the transmission window size or the reception window size is reconfigured the required buffer memory may temporarily exceed the size of the configured window and thus exceed the available buffer memory (see subclause 11.3.4.9).
If the parameter OSD_Window_Size is reconfigured:
– the UE shall remove from storage any PDUs whose sequence numbers, SN, are outside of the storage window VR(UOH) >= SN > VR(UOH) – OSD_Window_Size.
If the parameter DAR_Window_Size is reconfigured:
– the UE shall remove from storage any PDUs whose sequence numbers are outside of the storage window and deliver them to the higher RLC function to perform reassembly specified in subclause 11.2.3 and update the state variable VR(UDR) as specified in subclause 9.7.10;
– the UE shall update the state variables VR(UDT) and operate the timer Timer_DAR if needed (see subclause 9.7.10).
9.7.10 Duplicate avoidance and reordering for unacknowledged mode
The duplicate avoidance and reordering function can be configured for use within a receiving UM RLC entity in the UE. It combines PDU sequences received from several sources and/or repeat transmissions from a single source to form a single ordered PDU sequence that is passed to the header removal and reassembly functions. It completes duplicate detection, discard and re-ordering based on the UM PDU sequence number. Where the UM RLC receives input from several sources, inputs can be added or removed without changing the buffer contents, state variables and timers associated with the duplicate avoidance and reordering function or any subsequent UM RLC function.
The duplicate avoidance and reordering function makes use of the state variable VR(UDR) and a receive window whose span is from VR(UDH) – DAR_Window_Size + 1 to VR(UDH) inclusively. For re-ordering the function uses a buffer for the temporary storage of PDUs.
For each PDU received, the duplicate avoidance and reordering function shall (in the following SN denotes the sequence number of each PDU):
Setting initial values of state variables:
– If the PDU is the first PDU received by the duplicate avoidance and reordering function after establishment or re-establishment:
– VR(UDH) is assigned the value SN;
– VR(UDR) is assigned the value VR(UDH) – DAR_Window_Size + 1.
Duplicate detection and re-ordering:
– if SN is within the receive window:
– if SN < VR(UDR) or if a PDU with sequence number SN is already stored in the buffer:
– the PDU shall be discarded;
– else:
– the PDU shall be stored in the buffer.
– if SN is outside of the receive window:
– the PDU shall be stored in the buffer;
– VR(UDH) shall be assigned the value SN, thereby advancing the receive window;
– for any stored PDUs with sequence numbers < VR(UDH) – DAR_Window_Size + 1, i.e. outside the receive window after its position is updated, remove the PDU from the buffer and deliver them to the higher RLC function to perform the actions specified in subclause 11.2.3;
– if VR(UDR) < VR(UDH) – DAR_Window_Size + 1, i.e. VR(UDR) is outside the updated receive window;
– VR(UDR) shall be assigned the value VR(UDH) – DAR_Window_Size + 1.
– if PDU with sequence number VR(UDR) is stored in the buffer:
– for this PDU and any sequence of stored PDUs with consecutive sequence numbers starting at VR(UDR) + 1, remove the PDUs from the buffer and deliver them to the higher RLC function to perform the actions specified in subclause 11.2.3;
– VR(UDR) shall be assigned the value of x + 1 where x is the sequence number of the highest numbered PDU that was delivered to the higher RLC function.
Timer operation:
– if Timer_DAR is not active when a PDU is stored with SN > VR(UDR) by the duplicate avoidance and reordering function:
– Timer_DAR shall be started;
– VR(UDT) shall be assigned the value of the sequence number of the PDU.
– Timer_DAR shall be stopped:
– if the PDU with sequence number VR(UDT) is removed from the buffer before Timer_DAR expires.
– if Timer_DAR expires:
– for all stored PDUs with sequence numbers lower or equal to VR(UDT) and for any sequence of stored PDUs with consecutive sequence numbers starting at VR(UDT) + 1, remove the PDUs from the buffer and deliver them to the higher RLC function to perform the actions specified in subclause 11.2.3;
– VR(UDR) shall be assigned the value x + 1 where x is the sequence number of the highest numbered PDU that was delivered to the higher RLC function.
– When Timer_DAR is stopped or expires, and there remain PDUs stored by the duplicate avoidance and reordering function:
– Timer_DAR shall be started;
– VR(UDT) shall be assigned the sequence number of the highest numbered stored PDU.