6.5.3 Iu Rate Control procedure

25.4153GPPRelease 17TSUTRAN Iu interface user plane protocols

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.5.3.1 Successful operation

The purpose of the Iu Rate Control procedure is to signal to the peer Iu UP protocol layer the maximum rate over Iu in the reverse direction of the sent RATE CONTROL control frame.

The Rate Control procedure over Iu UP is normally controlled by the entity controlling the rate control over UTRAN i.e. the SRNC. The Iu Rate Control procedure is invoked whenever the SRNC decides that the maximum rate permitted downlink over Iu shall be modified, or when a RATE CONTROL control frame is received from the CN. Within the context of TrFO the SRNC may also receive RATE CONTROL control frames from the TrFO partner.

The rates that can be controlled by the SRNC are all the rates that are defined by the Iu-Initialisation procedure and which are above the guaranteed bitrate specified in the RAB parameters (indicated to the Iu UP at the RNC). Rates below or equal to the guaranteed bitrate, e.g. the lowest speech rate or the SID frames, cannot be controlled (i.e. cannot be forbidden) by the SRNC (exceptionally, in case of version 1 any of the initialised rates equal to or above the guaranteed bitrate can be controlled).

The procedure can be signalled at any time when Transfer of User Data procedure is not suspended by another Procedure Control function. When the user plane was initiated due to SRNS relocation reasons no rate control shall be signalled before the reception of the relocation execution trigger (see TS 25.413 [3]). At the reception of the relocation execution trigger the RNC shall start the Iu Rate Control procedure. This enables both TrFO partners to exchange current maximum rates and proceed user data transport based on latest rate decisions.

The Procedure Control function upon request of upper layer prepares the RATE CONTROL control frame payload containing the maximum rate of the reverse direction of the RATE CONTROL control frame. To align the Iu Rate Control procedure with version 1 of the Iu UP protocol the permitted maximum rate is given as a set of RFCI indicators, that shall contain the maximum rate and all rates below the maximum rate, i.e. all rate controllable and non rate controllable rates. In the context of TrFO and TFO the Iu Rate Control procedure may also be controlled by a remote peer.

The Frame Handler function calculates the frame CRC, formats the frame header into the appropriate PDU Type and sends the Iu UP frame PDU to the lower layers for transfer across the Iu interface.

A supervision timer T_RC is started after sending the Iu UP RATE CONTROL control frame. This timer supervises the reception of the rate control acknowledgement frame. Upon reception of a rate control acknowledgement frame, the Iu UP protocol layer in the SRNC stops the supervision timer T_RC.

Upon reception of a RATE CONTROL control frame, the Iu UP protocol layer checks the consistency of the Iu UP frame as follows:

– The Frame Handler function checks the consistency of the frame header and associated CRC. If correct, the Frame Handler function passes Procedure Control part to the procedure control functions;

– The Procedure Control functions check that all RFCIs in the initial RFCI set are indicated as either allowed or barred. If the whole rate control information is correct, the Procedure Control functions passes the rate control information to the NAS Data Streams specific functions;

– The NAS Data Streams specific functions forward to the upper layers the complete protocol data in a Iu-UP-Status indication primitive;

– Upon reception of the Iu-UP-Status request primitive, the Procedure Control functions shall acknowledge the RATE CONTROL control frame by including its own maximum rate control information i.e. the permitted rates in the reverse direction of the RATE CONTROL ACK message.

Figure 11: Successful Rate Control

Figure 12: Void

6.5.3.2 Unsuccessful operation

If the Iu UP protocol layer receives a RATE CONTROL control frame that is badly formatted or corrupted, it shall ignore the RATE CONTROL control frame, but send a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT control frame back (figure 13a).

Figure 13a: Negative Acknowledgement received from the peer

If the Iu UP in the SRNC detects that the RATE CONTROL control frame has not been correctly interpreted or received (e.g. the observed rate is outside the set of permitted rates in the reverse direction of the RATE CONTROL control frame (figure 13b), or a RATE CONTROL NEGATIVE ACKNOWLEDGEMENT control frame has been received, or no RATE CONTROL POSITIVE ACKNOWLEDGEMENT control frame was received before the supervision timer T_RC expires (Figure 13c)), the Iu UP shall retrigger a Iu Rate Control procedure. If after N _RC repetitions, the error situation persists, the Iu UP protocol layers (sending and receiving) take the appropriate local actions.

Figure 13: Unsuccessful Transfer of rate control from RNC: 1) Frame loss 2) Corrupted Frame

Figure 13b: Unsuccessful Transfer of rate control: undetected error

Figure 13c: Unsuccessful Transfer of rate control: lost rate control

6.5.3.2A Frequent Rate Control Procedures

Typically a new RATE CONTROL control frame should not be sent in the same direction before the previous Iu Rate Control procedure was terminated successfully.

If for some reasons (e.g. frequently received RATE CONTROL control frames from the CN in a TFO connection to GSM) a RATE CONTROL control frame has to be sent before the previous Iu Rate Control procedure was terminated successfully, then the previous Iu Rate Control procedure is defined as terminated successfully: the supervision timer T_RC shall be stopped and acknowledgement frames (positive or negative) for the previous RATE CONTROL control frame shall be ignored, i.e. only the most recent Iu Rate Control procedure shall be active in the same direction.

Figure 14: Frequent Rate Control: only most recent one is important

Figure 15: Void