Protocols

3.3.1

Radio Resource Control (RRC)

The following control plane functions are agreed in 3GPP to be performed by the Radio Resource Control (RRC) layer:

• Broadcast of System Information (SI) related to the NAS, • Broadcast of SI related to the AS,

• Paging,

• Establishment, maintenance and release of an RRC connection between the

UE and E-UTRAN including:

3.3 Protocols

◦ Configuration of radio resources for RRC connection including Signalling

Radio Bearer (SRB),

• Establishment, maintenance and release of point to point radio bearers, • Mobility functions including:

◦ UE measurement reporting and control of the reporting for inter-cell and

Inter Radio Access Technology (Inter-RAT) mobility,

◦ Inter-cell handover,

◦ UE cell selection and reselection and control of cell selection and reselec-

tion,

◦ UE context transfer between eNBs, • Notification for MBMS services,

• Establishment, configuration, maintenance and release of radio bearers for

MBMS services,

• QoS management functions. (Note: These functions are spread across multiple

layers),

• UE measurement reporting and control of the reporting, • MBMS control,

• NAS direct message transfer to/from NAS from/to UE.

On the network side, the RRC layer is terminated by the eNB.

RRC specification aspects

The RRC specification includes a hierarchy of procedures, where the highest level is called ”High-level procedures” covering e.g. Broadcast Control Channel (BCCH) ac- quisition, paging, RRC connection establishment, reestablishment, re-configuration and release. The content of high level procedure messages may then trigger Elemen- tary Procedures that execute e.g. measurement, radio resource or security configu- ration. Mobility is also described as an elementary procedure. A single high-level procedure may in some cases trigger multiple elementary procedures.

Relation between NAS and AS

The relation between NAS and AS states is characterised by the following principles, which is also illustrated in Figure 3.3.

• EMM-Deregistered & ECM-Idle ⇒ RRC IDLE: ◦ Mobility: PLMN selection,

◦ UE position: not known by the network. • EMM-Registered & ECM-Idle ⇒ RRC IDLE:

◦ Mobility: cell reselection,

Figure 3.3: Relation between NAS and AS.

• EMM-Registered & ECM-Connected with radio bearers established ⇒

RRC CONNECTED:

◦ Mobility: handover,

◦ UE position: known by the network at cell level.

3.3.2

Packet Data Convergence Protocol (PDCP)

Packet Data Convergence Protocol (PDCP) provides its services to the NAS/RRC at the UE or the relay at the eNB. The PDCP supports the following functions:

• Header compression and decompression of IP data flows using the ROHC pro-

tocol, at the transmitting and receiving entity, respectively.

• Transfer of data (user plane or control plane). This function is used for con-

veyance of data between users of PDCP services.

• Maintenance of PDCP sequence numbers for radio bearers mapped on RLC

acknowledged mode.

• In-sequence delivery of upper layer Packet Data Units (PDUs) at handover. • Duplicate elimination of lower layer SDUs at handover for radio bearers mapped

on RLC acknowledged mode.

• Ciphering and deciphering of user plane data and control plane data • Integrity protection of control plane data.

• Timer based discard.

3.3 Protocols

3.3.3

Radio Link Control (RLC)

The Radio Link Control (RLC) protocol supports an Unacknowledged Mode (UM) and an Acknowledged Mode (AM). Whether UM or AM is used is configured per radio bearer. For example, UM could be used for VoIP while AM is used to carry Transmission Control Protocol (TCP)-based traffic. An RLC transparent mode exists as well, but it shall be only used to send RRC messages when no RLC UM or AM entity is set up, yet.

The RLC layer supports segmentation and concatenation of RLC SDUs. Depending on the scheduler decision, a certain amount of data is selected from the RLC SDU buffer and segmented and/or concatenated depending on the size of the SDUs. This selected data block becomes the RLC PDU to which a sequence number is assigned. This means that one transport block contains only a single RLC PDU per radio bearer except if an RLC retransmission is required. In this case an RLC PDU containing new data might be multiplexed at the MAC layer with an RLC PDU retransmission. In order to allow the RLC SDU reassembly at the receiver, the RLC header carries the required segmentation, re-segmentation and concatenation information. The RLC sequence number will also be used at the receiver for in- sequence delivery to the RLC SDU reassembly entity.

In AM, RLC is responsible for correcting residual HARQ errors by operating another ARQ protocol since it would be expensive in terms of transmit power to reach the required residual error rates of 10−5 or less in the MAC HARQ protocol.

The ARQ retransmission units are RLC PDUs or RLC PDU segments. If an RLC retransmission is required and the radio quality has changed significantly com- pared to the original RLC transmission, the RLC protocol is able to perform a re-segmentation. In this case RLC segments a PDU into smaller PDU segments. The number of RLC re-segmentations of an RLC PDU is unlimited.

RLC performs reordering of received RLC PDUs and PDU segments in order to ensure that RLC SDUs are delivered in sequence to higher layers.

Retransmissions are initiated either by status reports sent by the RLC receiver or by local triggers from MAC layer in case of reaching the maximum number of HARQ transmissions. Status Reports are triggered either by polls sent from the RLC sender or by detecting missing PDUs after the PDUs have passed the reordering entity. Similar to UTRAN, the LTE RLC supports a status prohibit timer and a poll timer.

Finally, RLC provides means for protocol error detection and recovery (e.g. reset) and duplicate detection.

3.3.4

Medium Access Control (MAC)

The Medium Access Control (MAC) layer for the LTE access can be compared to the Release 6 MAC-hs/MAC-e and covers mainly similar functionality: HARQ, priority handling (scheduling), transport format selection and Discontinuous Recep- tion (DRX) control (not part of MAC in Release 6).

The HARQ protocol is very similar to the solution adopted for High Speed Down- link Packet Access (HSDPA), i.e., the protocol uses multiple stop-and-wait hybrid

ARQ processes. The motivation for this type of protocol is to allow continuous transmission, which cannot be achieved with a single stop-and-wait scheme, while at the same time having some of the simplicity of a stop-and-wait protocol. The functionality and performance is similar to that of a window based selective repeat protocol but only single-bit HARQ feedback is required.

The protocol is modelled as a number of parallel HARQ processes, where each process uses a simple stop-and-wait protocol. By using NHARQ parallel HARQ processes, where NHARQ > Round trip time/Subframe length, a continuous trans- mission is achieved. The maximum UE processing time before sending a HARQ feedback has been specified such that 8 HARQ processes are needed for continuous transmission in FDD with a typical eNB implementation.

In 3GPP, the current working assumption is to use a synchronous HARQ for the uplink and an asynchronous HARQ for the downlink. That is, for the uplink, the subframe when the retransmission occurs is known at the receiver, while for the downlink the scheduler has the freedom to choose the subframe for the retransmis- sion dynamically. For both up- and downlink a synchronous, single-bit HARQ feed- back Acknowledge (ACK)/Negative Acknowledge (NACK) is sent providing feed- back about the success of the previous transmission. The HARQ protocol is adap- tive in both uplink and downlink, meaning that the scheduler can decide to use a different resource for a retransmission compared to that one used for the previous (re)transmission.

The redundancy version of a (re)transmission needs to be known by the receiver. Thus, the redundancy version and an indication whether the transmission contains a first transmission or a retransmission is indicated on the Physical Downlink Control Channel (PDCCH). In case the data is a retransmission of previously stored data, the received data is soft combined with the data stored in the soft buffer. In case the received data is not a retransmission or a retransmission of data that has not been stored, the soft buffer is cleared and only the latest received data is placed in the buffer.

The Figure 3.4 presents the principle of HARQ operation for MAC layer.

Figure 3.4: HARQ principle - four multiple HARQ processes.

The MAC layer does not support in-order delivery to RLC. HARQ retransmissions will lead to that MAC PDUs are received in a different order than they were sent. Due to the lack of MAC sequence numbers it is up to the RLC receivers to restore the original sequence and to provide in-order delivery to higher layers.