3gpp tsg geran adhoc #2 Tdoc geran adhoc 025/00 Munich, Germany Agenda item 3 9th –13th October, 2000




Дата канвертавання19.04.2016
Памер20.35 Kb.

3GPP TSG GERAN Adhoc #2 Tdoc GERAN Adhoc 025/00

Munich, Germany Agenda item 6.1.3
9th –13th October, 2000



Source: Ericsson

RLC with limited retransmissions for streaming service class

1Introduction


GERAN R’00 will provide a certain bearer type which supports streaming applications. Although streaming services are not very delay sensitive a maximum delay has to be guaranteed. A streaming bearer will be used in acknowledged mode and erroneous PDUs are retransmitted. If the maximum delay is exceeded, i.e. a SDU has not arrived before the play out time, further (re-)transmissions of any of the belonging PDUs are useless. To save resources on the air interface all corresponding PDUs should be removed from both transmitter and receiver window.
There is one solution which was presented at Adhoc #1 in Seattle [2]. In this document, we propose an alternative solution which is similar to the SDU discard mechanism standardized for UTRAN [1].

2Brief description of the solution proposed at the Adhoc meeting in Seattle [2]


The actual SDU discard function is receiver driven. A requirement for this approach is to inform the receiver about the time an SDU was delivered to the transmitter RLC entity by the higher layer and about the maximum allowed delay. Therefore each SDU could be time-stamped. But that would increase the packet overhead drastically and is therefore not applicable. It was suggested to set a single bit (UTR – update time reference) in the RLC/MAC header of those PDUs not experiencing any queuing delay. If this bit is set the receiver uses the arrival time as new time reference. All following play out times are calculated using
this offset (),

the maximum allowed delay (D),

the play out rate (R) and

the amount of data contained in one RLC block (B).


“If an RLC block is not received at least one round trip delay, T, prior to the play out time, then its receipt status is set to ‘1’ (acknowledged). This means that it will be acknowledged the next time the receiver is polled for feedback and the transmitter will not attempt further recovery for the block. If the RLC block is not received by the play out time, the receiver RLC indicates a loss to the higher layer.”
The main drawback of this approach is that the variables listed above have to be constant to ensure that the algorithm works. But if a video stream is transmitted the size of the packets (pictures) varies strongly. Also the amount of data contained in one RLC block varies if link adaptation is used. Consequently, the formula behaves incorrect especially if the interval between two time synchronization attempts is long. This happens if the link gets worse and the amount of data to be transmitted is high for a while. Then it would be necessary to update the time reference but new packets are queued and can’t be used to carry the UTR bit.
Another problem is that every packet is transmitted at least once even if the play out time is already exceeded. An RLC PDU that is buffered but has not been transmitted yet is not included in the transmitter window. A positive acknowledgement sent by the receiver is ignored and the packet is transmitted nevertheless. Thus, this proposal is not suited to solve heavy congestion in case the available data rate drops significantly for some time.
Furthermore, the UTR bit that is required for this approach has to be placed in the RLC/MAC header. But especially in the downlink there are no spare bits available that could be used.


3Alternative solution


We think that the SDU discard mechanism as standardized for UTRAN is a well suited approach and should be used in GERAN with some modifications. This solution is described in [1] as follows:
9.7.3 SDU discard function

The SDU discard function allows to discharge RLC PDU from the buffer on the transmitter side, when the transmission of the RLC PDU does not success for a long time. The SDU discard function allows to avoid buffer overflow. There will be several alternative operation modes of the RLC SDU discard function, and which discard function to use will be given by the QoS requirements of the Radio Access Bearer.

The following is a list of operation modes for the RLC SDU discard function.
Table 9.2: List of criteria's 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 retransmissions

Network controlled


9.7.3.1 Timer based discard, with explicit signalling

This alternative 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 a higher layer, timer monitoring of the transmission time of the SDU is started. If the transmission time exceeds a predefined value for a SDU in acknowledged mode RLC, this SDU is discarded in the transmitter and a Move Receiving Window (MRW) command is sent to the receiver so that AMD PDUs carrying that SDU are discarded in the receiver and the receiver window is updated accordingly. Note that when the concatenation function is active, PDUs carrying segments of other SDUs that have not timed out shall not be discarded.

The MRW command is defined as a super-field in the RLC STATUS PDU (see subclause 9.2), and piggy backed to status information of transmissions in the opposite direction. If the MRW command has not been acknowledged by receiver, it will be retransmitted. Therefore, SDU discard variants requiring peer-to-peer signalling are only possible for full duplex connections.
9.7.3.2 Timer based discard, without explicit signalling

This alternative 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. This function is applied only for unacknowledged and transparent mode RLC and peer-to-peer signalling is never needed. The SDUs are simply discarded in the transmitter, once the transmission time is exceeded.
9.7.3.3 SDU discard after MaxDAT number of retransmissions

This alternative uses the number of retransmissions as a trigger for SDU discard, and is therefore only applicable for acknowledged mode RLC. This makes the SDU discard function dependent of 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. SDU discard is triggered at the transmitter, and a MRW command is necessary to convey the discard information to the receiver, like in the timer based discard with explicit signalling.

It can be concluded that three different functions can be used. All of them are transmitter controlled, i.e. the transmitter decides if an SDU is too old an should be deleted. If the timer that has to be started for each PDU expires all PDUs belonging to the SDU are removed from the transmitter window and a ‘Move Receiver Window’-Message (MRW) is sent to the receiver. As soon as the receiver gets this message the window is moved to the specified position. This solutions solves the problems which are expected for the proposal presented in [2]. Since the transmitter knows the SDU arrival times as well as the allowed delay it can decide more precisely when to discard SDUs. Furthermore, the transmit can discard SDUs without sending them at all. This is very useful in case of heavy congestion or very low available bandwidth.

The drawback of this solution is that a separate control message (MRW-message) has to be transmitted to initiated the move of the receiver window. This decreases the efficiency of the bandwidth utilization.

It is for further study if there are other solutions like inband signalling or ‘no signalling’ which can incorporate the MRW functionality.



4References


  1. 3G TS 25.322 V3.3.0, Technical Specification, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; RLC Protocol Specification, (Release 1999).

  2. RLC with Limited Retransmissions for Streaming Service Class, Tdoc GERAN Adhoc 0116/00, 3GPP TSG GERAN Meeting #1 (Seattle)

()


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка