on). Most RRC connection control actions are atomic: Only one connection control task can operate at the same time. There are some exceptions (e.g. reporting certain fail- ures and providing UE assistance information to the network), but the main principle is that the UE executes one RRC command at a time, and each RRC command must be completed before executing the next one. This obviously also means that if the network wishes to perform two successive commands that modify the UE RRC context, the sec- ond one has to take the results of the first one into account. It is still possible to send multiple RRC messages to be "buffered" for the UE, but since they are processed in the 7.7 The RRC Protocol order they are received, the network has to ensure that nothing would happen to create inconsistency in the referred RRC context. Certain RRC connection control messages carry RRC transaction identifiers (RTIs), which are used by the UE to ensure that no duplicate RRC messages are acted upon (if the same RRC message is repeated due to errors), as well as by the network to identify when the UE has finished applying a particular RRC message. Thus, the RTI is always first inserted by the network in a downlink RRC message, and then echoed back to the net- work in the corresponding uplink RRC message acknowledgment (if that is sent - there are some cases when there is no UL response). The rules determining when the RTI is included are quite straightforward: for the downlink, RRC messages typically include the RTI, and the UE always uses the same RTI when responding to the message. The exceptions to this are messages that push UE to IDLE/INACTIVE, or broadcast mes- sages. For the uplink, an RRC message that would require a network response uses the RTI as does the UE response to a downlink RRC message. Otherwise, uplink messages do not include the RTI. Tables 7.4 and 7.5 illustrate the RRC messages that do and do not include the RTI, with explanations of why the RTI is or is not included. 7.7.5.2 RRC Connection Setup from IDL