Three RLC Transmission Modes

The RLC Layer of a wireless link control protocol is located on the MAC layer to provide segmentation and retransmission services for users and control data. Each RLC entity is configured by RRC and has three modes based on the business type: transparent mode (TM), non-validation mode (UM), and validation mode (AM ).

For the transparent mode and non-validation mode, the RLC entity is unidirectional and each has a sending entity and a Receiving Entity to independently send and receive data. For the validation mode, the RLC object is bidirectional. Although there is only one entity, it is divided into the receiving side and the sending side to complete the data sending and receiving function. And they can communicate with each other.
For all RLC modes, CRC verification is completed in the physical layer. The verification results and corresponding data are indirectly transferred to the RLC Layer.

The actual operations of the two RLC modes are as follows:
Transparent mode: The sending entity does not add any extra control on the overhead of the external protocol on the high-level data. It only determines whether to perform segment operations based on the business type. If an error occurs in the PDU received by the Receiving Entity, submit or directly discard the PDU after the error mark based on the configuration and report it to the higher level. The real-time speech Service generally adopts the RLC transparent mode.
Non-validation mode: The sending entity adds the necessary control protocol overhead on the top PDU, and then transmits but does not guarantee the transfer to the peer entity, and the retransmission protocol is not used. The Receiving Entity submits the received error data after marking it as an error, or directly discards it and reports it to the senior management. Because the rlc pdu contains a sequence number, it can detect the integrity of the high-level PDU. Um-based businesses include residential broadcasting and IP phones.
Validation mode: The sending side adds necessary control protocol overhead to the High-Level Data for transmission, and ensures that the transfer is passed to the peer entity. Because of its ARQ capability, if the RLC receives the wrong rlc pdu, it notifies the sender of RLC re-transmitting the PDU. Because the rlc pdu contains sequential numbers, data can be submitted to the high-level in order or out of order. The am mode is the standard mode for group data transmission, such as WWW and email download.

 

Performance Comparison of Three rlc tm/UM/AM modes
at present, the RLC Layer supports three modes: TM/UM/AM. The selection of this mode depends on the QoS of the wireless bearer.
TM/um is designed for real-time services. For some real-time services, the main goal is to require a minimum latency and allow certain data losses. To meet this requirement, the RLC must support immediate submission. If RLC retransmission is used in real-time services, there is a long round-trip latency between the wireless interface and the Iub interface, which causes a large latency in The RLC, this will seriously reduce the service QoS and increase the additional buffer overhead.
am is designed for non-real-time services and has different features from TM/um. Non-real-time services can tolerate a certain degree of latency, but require higher transmission quality. Therefore, it is crucial to use ARQ retransmission mechanism in AM mode. Therefore, am RLC requires some additional features and parameters to implement retransmission to provide QoS required by non-real-time services. The cost of RLC retransmission is increased latency. The latency of a retransmission cannot exceed 150 ms.
in short, the choice of TM/UM/AM mode is mainly based on the business characteristics.
TM/um: latency-sensitive, error-insensitive, no feedback, no re-transmission required. Therefore, it is often used for real-time services (such as session services and Stream Services).
AM: It is not sensitive to latency, error, feedback, and retransmission. Therefore, it is often used for non-real-time services (interactive services and background services ).
however, there are some special requirements for some businesses, such as sensitive to latency, immediate submission of requirements, and re-transmission when an error occurs, but report feedback is required to understand the status information. For example, the real-time IP address grouping Service Based on rohc (RFC 3095 and PDCP), although it is a real-time service, however, we also need to provide feedback to adjust the compression algorithm . Currently, TM/UM/am cannot meet the requirements of such business features. Therefore, there are also a lot of research on whether a new RLC Transmission Mode is required to support such businesses.