B.2 Protocol state model for support mode for predefined SDU sizes
25.4153GPPRelease 17TSUTRAN Iu interface user plane protocols
Figure B.2 illustrates the state model for support mode Iu UP instances. A support mode instance can be in one of the following states.
Figure B.2: Protocol state model for support mode
B.2.1 Null State
In the null state the Iu UP instance does not exist and therefore it is not possible to transfer any data through it.
Upon reception of a Iu-UP-CONFIG-Req from higher layer the Iu UP instance is created and initialisation state is entered. In the Iu-UP-CONFIG-Req e.g. the following information could be indicated:
– Support mode for predefined SDU sizes;
– Time alignment (FFS);
– Indication of delivery of erroneous SDUs;
– Periodicity;
– required UP versions.
B.2.2 Initialisation State
In the initialisation state the instance exchanges initialisation information with its peer Iu UP instance.
Upon reception of Iu-UP-CONFIG-Req indicating release from higher layer, the Iu UP instance is terminated and the null state is entered.
Upon sending or receiving of an INITIALISATION control frame the Iu UP instance remains in the Initialisation state. The sending side starts a supervision timer TINIT. The receiving side acknowledges the INITIALISATION control frame with a positive acknowledgement or a negative acknowledgement.
Upon reception of the last initialisation acknowledgement frame, the supervision timer TINIT is stopped and the Iu UP instance enters SMpSDU data transfer ready state.
After sending a positive acknowledgement of the last INITIALISATION control frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that CN does not know if the initialisation ACK was correctly received by the RNC (and Initialisation procedure successfully completed) until it receives RAB assignment response, or use data from the RNC. The CN must therefore be able to continue receiving INITIALISATION control frames by re-entering the Initialisation state (from Support Mode Data Transfer Ready State), if the CN has started to send user data before receiving the indication that Initialisation was successfully completed.
Upon reception of an INITIALISATION NEGATIVE ACKNOWLEDGEMENT control frame (INIT NACK) initialisation frame can be repeated n times.
If after n repetitions, the Initialisation procedure is unsuccessfully terminated (due to n negative acknowledgements or timer expires) the Handling of Error Event procedure is used to report the Initialisation failure and the Iu UP instance remains in the initialisation state. Upon reception of an INITIALISATION control frame the Initialisation state is entered.
B.2.3 Support Mode Data Transfer Ready State
In the support mode data transfer ready state, support mode data can be exchanged between the peer Iu UP instances.
Upon reception of Iu-UP-DATA-Request from the upper layer or SSSAR-UNITDATA-Indication or Iu‑UP‑UNITDATA-Indication from TNL layer, appropriate user data transfer procedures are performed. Iu UP instance remains in the SMpSDU data transfer ready state.
Upon sending of Iu-UP-DATA- Indication or SSSAR-UNITDATA-Request or Iu-UP-UNITDATA-Request the Iu UP instance remains in the SMpSDU data transfer ready state.
Upon sending or receiving of a rate control PDU the Iu UP instance remains in the SMpSDU data transfer ready state.
Upon sending of a Iu-UP-STATUS-Indication (rate control) the Iu UP instance remains in the SMpSDU data transfer ready state.
Upon reception of Iu-UP-CONFIG-Req from higher layer the Iu UP instance is terminated and the null state is entered.
Upon detection of a protocol fault, Iu-UP-STATUS-Indication is sent to upper layer an ERROR EVENT control frame may be sent over Iu UP.
In case of handover or relocation, Initialisation procedures may have to be performed and Iu UP instance may have to enter the initialisation state.
Annex C (informative):
Open Issues of the Iu UP
This annex contains information related to open issues left in the Iu UP protocol.
Annex D (informative):
Distributed rate decision within RNC
This annex contains information related to the distributed rate decision within an RNC (see also within TS 23.153 [13])
The Iu Rate Control procedure over Iu UP is normally controlled by the entity controlling the rate control over UTRAN i.e. the SRNC. The SRNC may send RATE CONTROL control frames in uplink (to the CN) to control the rates in downlink. The SRNC may also send RATE CONTROL control frames in downlink (to the UE) to control the rates in uplink. The Iu Rate Control procedures for both directions are independent of each other, i.e. different rates may be permitted in uplink and downlink, see figure D.1.
Figure D.1: Rate Control for uplink and downlink
The rates associated with the service could be rank ordered from "lower" to "higher" according to their SDU bit rates and RFCI values, with RFCI=0 having the lowest rate. A rate lower than the currently allowed maximum rate shall not be forbidden while a higher rate is forbidden. In order to stabilise the Iu Rate Control procedure and its influences on the radio link and the network, typically only one additional rate shall be forbidden or permitted in subsequent RATE CONTROL control frames.
In some cases, as TrFO and TFO, the rate is also controlled by the remote partner at the other end of the Iu UP. The SRNC may then also receive RATE CONTROL control frames in downlink (from the CN) controlling the rates in uplink. Only rates that are permitted by both sides for one direction shall be used in that direction. The SRNC shall therefore combine these RATE CONTROL control frames from the CN with its own control frames for the uplink direction by taking the RATE CONTROL control frame with the lowest maximum rate and shall send this RATE CONTROL control frame downlink to the UE. This combination is denoted in figure D.2 with "Rate Control (CN RNC)".
Figure D.2: Distributed Rate Control for uplink and downlink
Annex E (informative):
Change History
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
New |
|
12/2008 |
– |
– |
– |
– |
Creation of Rel-8 version based on v7.3.0 |
8.0.0 |
|
12/2009 |
– |
– |
– |
– |
Creation of Rel-9 version based on v8.0.0 |
9.0.0 |
|
03/2011 |
SP-49 |
SP-100629 |
Clarification on the use of References (TS 21.801 CR#0030) |
9.0.1 |
||
|
03/2011 |
Creation of Rel-10 version based on v9.0.1 |
10.0.0 |
||||
|
06/2011 |
RP-52 |
SP-110685 |
0134 |
– |
Reference review outcome in TS 25.415 |
10.1.0 |
|
09/2012 |
Update to Rel-11 version (MCC) |
11.0.0 |
||||
|
09/2014 |
Update to Rel-12 version (MCC) |
12.0.0 |
||||
|
12/2015 |
Update to Rel-13 version (MCC) |
13.0.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
SA#75 |
Promotion to Release 14 without technical change |
14.0.0 |
||||
|
2018-07 |
SA#80 |
– |
– |
– |
– |
Promotion to Release 15 without technical change |
15.0.0 |
|
2020-07 |
SA#88-e |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
SA#95-e |
Promotion to Release 17 without technical change |
17.0.0 |
||||