LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 1

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 2

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 3

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 4

LTE MAC, RLC and PDCP

The following functions are supported by MAC sublayer: - mapping between logical channels and transport channels; - multiplexing of MAC SDUs from one or different logical channels onto transport blocks (TB) to be delivered to the physical layer on transport channels; - demultiplexing of MAC SDUs from one or different logical channels from transport blocks (TB) delivered from the physical layer on transport channels; - scheduling information reporting; - error correction through HARQ; - priority handling between UEs by means of dynamic scheduling; - priority handling between logical channels of one UE; - Logical Channel prioritisation; -transport format selection. NOTE: How the multiplexing relates to the QoS of the multiplexed logical channels is FFS.

K Labs S.r.l. all right reserved

Cap 5 - pag. 5

LTE MAC, RLC and PDCP

The physical layer specifi cations are split into four main sections. TS36.211 physical channels and modulation This specifi cation describes the uplink and downlink physical signals and physical channels, how they are modulated, and how they are mapped into the frame structure. Included is the processing for the support of multiple antenna techniques. TS 36.212 multiplexing and channel coding This specifi cation describes the transport channel and control channel data processing, including multiplexing, channel coding schemes, coding of L1 and L2 control information, interleaving, and rate matching. TS 36.213 physical layer procedures This specifi cation describes the characteristics of the physical layer procedures including synchronization procedures, cell search and timing synchronization, power control, random access procedure, CQI reporting and MIMO feedback, UE sounding, HARQ, and ACK/NACK detection. TS 36.214 physical layer measurements This specifi cation describes the characteristics of the physical layer measurements to be performed in Layer 1 by the UE and eNB, and how these measurement results are reported to higher layers and the network. This specification includes measurements for handover support. TS 36.133 radio resource management Although not strictly a part of the physical layer, the requirements for radio resource management (RRM) are summarized here since they are closely linked to the physical layer measurements.

K Labs S.r.l. all right reserved

Cap 5 - pag. 6

LTE MAC, RLC and PDCP

The physical channels defined in TS 36.21110 are mapped to transport channels (TrCH) that carry information between the physical layer and the MAC and higher layers. Types of downlink and uplink TrCH are described in TS 36.300 V8.3.0.5 The TrCH specifications are documented in TS 36.212.12

K Labs S.r.l. all right reserved

Cap 5 - pag. 7

LTE MAC, RLC and PDCP

The physical channels defined in TS 36.21110 are mapped to transport channels (TrCH) that carry information between the physical layer and the MAC and higher layers. Types of downlink and uplink TrCH are described in TS 36.300 V8.3.0.5 The TrCH specifications are documented in TS 36.212.12

K Labs S.r.l. all right reserved

Cap 5 - pag. 8

LTE MAC, RLC and PDCP

The physical channels defined in TS 36.21110 are mapped to transport channels (TrCH) that carry information between the physical layer and the MAC and higher layers. Types of downlink and uplink TrCH are described in TS 36.300 V8.3.0.5 The TrCH specifications are documented in TS 36.212.12

K Labs S.r.l. all right reserved

Cap 5 - pag. 9

LTE MAC, RLC and PDCP

The physical channels defined in TS 36.211 are mapped to transport channels (TrCH) that carry information between the physical layer and the MAC and higher layers. Types of downlink and uplink TrCH are described in TS 36.300 V8.3.0.5 The TrCH specifications are documented in TS 36.212.12

K Labs S.r.l. all right reserved

Cap 5 - pag. 10

LTE MAC, RLC and PDCP

The data and control streams to and from the MAC layer are encoded and decoded using channel coding schemes. Channel coding combines error detection, error correcting, rate matching, interleaving, and transport channel or control information mapping onto or splitting from physical channels. Two channel coding schemes are used in LTE for the TrCH: turbo coding for the UL-SCH, DL-SCH, PCH, and MCH; and tail-biting convolutional coding for the BCH. For both schemes, the coding rate is R=1/3 (that is, for every bit that goes into the coder, three bits come out). Control information is coded using various schemes, including tail-biting convolutional coding, and various control rates. The precise details of the physical layer processing for the TrCH vary by TrCH type and are specifi ed throughout TS 36.212.

K Labs S.r.l. all right reserved

Cap 5 - pag. 11

LTE Architecture and Air Interface

The data and control streams to and from the MAC layer are encoded and decoded using channel coding schemes. Channel coding combines error detection, error correcting, rate matching, interleaving, and transport channel or control information mapping onto or splitting from physical channels. Two channel coding schemes are used in LTE for the TrCH: turbo coding for the UL-SCH, DL-SCH, PCH, and MCH; and tail-biting convolutional coding for the BCH. For both schemes, the coding rate is R=1/3 (that is, for every bit that goes into the coder, three bits come out). Control information is coded using various schemes, including tail-biting convolutional coding, and various control rates. The precise details of the physical layer processing for the TrCH vary by TrCH type and are specifi ed throughout TS 36.212.

K Labs S.r.l. all right reserved

Cap 2 - pag. 12

LTE MAC, RLC and PDCP

The scheme of turbo encoder is a Parallel Concatenated Convolutional Code (PCCC) with two 8-state constituent encoders and one turbo code internal interleaver. The coding rate of turbo encoder is 1/3.

K Labs S.r.l. all right reserved

Cap 5 - pag. 13

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 14

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 15

LTE MAC, RLC and PDCP

Random access preamble The physical layer random access burst consists of a cyclic prefix, a preamble, and a guard time during which nothing is transmitted. The random access preambles are generated from Zadoff-Chu sequences with zero correlation zone, ZC-ZCZ, generated from one or several root Zadoff-Chu sequences.

K Labs S.r.l. all right reserved

Cap 5 - pag. 16

LTE MAC, RLC and PDCP

Figure shows the processing structure for the UL-SCH transport channel. The following coding steps can be identified: Add CRC to the transport block (24 bit) Code block segmentation and code block CRC attachment Channel coding of data and control information HARQ & Rate matching Code block concatenation Multiplexing of data and control information Channel interleaver Channel coding of control information Control data arrives at the coding unit in the form of channel quality information (CQI and/or PMI), HARQ-ACK and rank indication. Different coding rates for the control information are achieved by allocating different number of coded symbols for its transmission. When control data are transmitted in the PUSCH, the channel coding for HARQ-ACK, rank indication and channel quality information oi is done independently. For TDD, two ACK/NACK feedback modes are supported by higher layer configuration. ACK/NACK bundling, and ACK/NACK multiplexing For TDD ACK/NACK bundling, HARQ-ACK consists one or two bits information. For TDD ACK/NAK multiplexing, HARQ-ACK consists of between one and four bits of information and the number of bits is determined as described in Section 7.3 in [3].

K Labs S.r.l. all right reserved

Cap 5 - pag. 17

LTE MAC, RLC and PDCP

The physical-layer model for Uplink Shared Channel transmission is described based on the corresponding physical-layer-processing chain. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher layers, are highlighted in blue. It should be noted that, in case PUSCH, the scheduling decision is partly made at the network side, if there is no blind decoding it is fully done at the network side. The uplink transmission control in the UE then configures the uplink physical-layer processing, based on uplink transport-format and resource-assignment information received on the downlink. - Higher-layer data passed to/from the physical layer - One transport block of dynamic size delivered to the physical layer once every TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 Hybrid-ARQ process controls what redundancy version is to be used for the physical layer transmission for each TTI. - Interleaving - No control of interleaving by higher layers. - Data modulation - Modulation scheme is decided by MAC Scheduler (QPSK, 16QAM and 64QAM). - Mapping to physical resource - L2-controlled resource assignment. - Multi-antenna processing - MAC Scheduler partly configures mapping from assigned resource blocks to the available number of antenna ports. - Support of L1 control signalling - Transmission of ACK/NAK and CQI feedback related to DL data transmission - Transport via physical layer of Hybrid-ARQ related information (exact info is FFS) associated with the PUSCH, to the peer HARQ process at the receiver side; - Transport via physical layer of corresponding HARQ acknowledgements to PUSCH transmitter side.

K Labs S.r.l. all right reserved

Cap 5 - pag. 18

LTE MAC, RLC and PDCP

The PUCCH shall be mapped to a control channel resource in the uplink. A control channel resource is defined by a code and two resource blocks, consecutive in time, with hopping at the slot boundary. Depending on presence or absence of uplink timing synchronization, the uplink physical control signalling can differ. In the case of time synchronization being present, the outband control signalling consists of: - CQI; - ACK/NAK; - Scheduling Request (SR). The CQI informs the scheduler about the current channel conditions as seen by the UE. If MIMO transmission is used, the CQI includes necessary MIMO-related feedback. The HARQ feedback in response to downlink data transmission consists of a single ACK/NAK bit per HARQ process. PUCCH resources for SR and CQI reporting are assigned and can be revoked through RRC signalling. An SR is not necessarily assigned to UEs acquiring synchronization through the RACH (i.e. synchronised UEs may or may not have a dedicated SR channel). PUCCH resources for SR and CQI are lost when the UE is no longer synchronized. The HARQ acknowledgement bits are received from higher layers. HARQACK consists of 1-bit of information, i.e., or 2-bits of information, i.e., with corresponding to ACK/NACK bit for codeword 0 and corresponding to that for codeword 1. Each positive acknowledgement (ACK) is encoded K Labs S.r.l. all right reserved Cap 5 - pag. 19 as a binary 1 and each negative acknowledgement (NACK) is encoded as a

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 20

LTE MAC, RLC and PDCP

The physical-layer model for BCH transmission is characterized by a fixed pre-defined transport format. The TTI (repetition rate) of the BCH is 40 ms. The BCH physical-layer model is described based on the corresponding BCH physical-layer-processing chain: - Higher-layer data passed to/from the physical layer - A single (fixed-size) transport block per TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - No BCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. - Interleaving - No control of interleaving by higher layers. - Data modulation - Fixed modulation scheme (QPSK), i.e. not higher-layer control. - Mapping to physical resource - Fixed pre-determined transport format and resource allocation, i.e. no higher-layer control. - Multi-antenna processing Fixed pre-determined processing, i.e. no higher-layer control. - Support for Hybrid-ARQ-related signalling - No Hybrid ARQ.
K Labs S.r.l. all right reserved

Cap 5 - pag. 21

LTE MAC, RLC and PDCP

The physical-layer model for Downlink Shared Channel transmission model is described based on the corresponding PDSCH physical-layer-processing chain. Processing steps that are relevant for the physicallayer model, e.g. in the sense that they are configurable by higher layers, are highlighted in blue on the figure. - Higher-layer data passed to/from the physical layer - N (up to two) transport blocks of dynamic size delivered to the physical layer once every TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 Hybrid-ARQ process controls what redundancy version is to be used for the physical layer transmission for each TTI. - Interleaving - No control of interleaving by higher layers. - Data modulation - Modulation scheme is decided by MAC Scheduler (QPSK, 16QAM and 64 QAM). Multi-antenna processing - MAC Scheduler partly configures mapping from modulated code words (for each stream) to the available number of antenna ports. - Mapping to physical resource - L2-controlled resource assignment. - Support of L1 control signalling - Transmission of scheduler related control signals. -Support for Hybrid-ARQ-related signalling NOTE: The signalling of transport-format and resource-allocation is not captured in the physical-layer model. At the transmitter side, this information can be directly derived from the configuration of the physical layer. The physical layer then transports this information over the radio interface to its peer physical layer, presumably multiplexed in one way or another with the HARQ-related information. On the receiver side, this information is, in contrast to the HARQ-related information, used directly within the physical layer for PDSCH demodulation, decoding etc., without passing through higher layers.

K Labs S.r.l. all right reserved

Cap 5 - pag. 22

LTE MAC, RLC and PDCP

The physical-layer model for Downlink Shared Channel transmission model is described based on the corresponding PDSCH physical-layer-processing chain. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher layers, are highlighted in blue on the figure. - Higher-layer data passed to/from the physical layer - N (up to two) transport blocks of dynamic size delivered to the physical layer once every TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 Hybrid-ARQ process controls what redundancy version is to be used for the physical layer transmission for each TTI. - Interleaving - No control of interleaving by higher layers. - Data modulation - Modulation scheme is decided by MAC Scheduler (QPSK, 16QAM and 64 QAM). Multi-antenna processing - MAC Scheduler partly configures mapping from modulated code words (for each stream) to the available number of antenna ports. - Mapping to physical resource - L2-controlled resource assignment. - Support of L1 control signalling - Transmission of scheduler related control signals. -Support for Hybrid-ARQ-related signalling NOTE: The signalling of transport-format and resource-allocation is not captured in the physical-layer model. At the transmitter side, this information can be directly derived from the configuration of the physical layer. The physical layer then transports this information over the radio interface to its peer physical layer, presumably multiplexed in one way or another with the HARQ-related information. On the receiver side, this information is, in contrast to the HARQ-related information, used directly within the physical layer for PDSCH demodulation, decoding etc., without passing through higher layers.

K Labs S.r.l. all right reserved

Cap 5 - pag. 23

LTE MAC, RLC and PDCP

The physical-layer model for PCH transmission is described based on the corresponding PCH physical-layer-processing chain. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher layers, are highlighted in blue on the figure. - Higher-layer data passed to/from the physical layer - A single transport block per TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - No PCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. - Interleaving - No control of interleaving by higher layers. - Data modulation - Modulation scheme is decided by MAC Scheduler. - Mapping to physical resource - L2 controlled resource assignment; - Possible support of dynamic transport format and resource allocation. - Multi-antenna processing - MAC Scheduler partly configures mapping from assigned resource blocks to the available number of antenna ports. - Support for Hybrid-ARQ-related signalling No Hybrid ARQ.

K Labs S.r.l. all right reserved

Cap 5 - pag. 24

LTE MAC, RLC and PDCP

The physical-layer model for MCH transmission is characterized by the support for multi-cell reception at the UE (a.k.a. SFN transmission). This implies that only semi-static configuration of the MCH transport format and resource assignment is possible. The MCH physical-layer model is described based on the corresponding PCH physical-layer-processing chain. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher layers, are highlighted in blue. - Higher-layer data passed to/from the physical layer - One transport block delivered to physical layer once every TTI. - CRC and transport-block-error indication - Transport-block-error indication delivered to higher layers. - FEC and rate matching - Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and resource assignment; - No MCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. - Interleaving - No control of interleaving by higher layers. - Data modulation - Modulation scheme is decided by MAC Scheduler. - Mapping to physical resource - L2 controlled semistatic resource assignment. - Multi-antenna processing - MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available number of antenna ports. - Support for Hybrid-ARQ-related signalling - No Hybrid ARQ.

K Labs S.r.l. all right reserved

Cap 5 - pag. 25

LTE MAC, RLC and PDCP

PDCCH allocates resources to the UE for receiving the PDSCH. There are three types of allocation mechanisms varying from a simple bitmap (type 0) through the most complex (type 2), which also has the most flexibility. In order that the UE can identify whether it has received a PDCCH transmission correctly, error detection is provided by means of 16-bit CRC appended to each PDCCH. Furthermore it is necessary that the UE can identify which PDCCH(s) are intended for it. This could in theory be achieved by adding an identifier to the PDCCH payload, however, it turns out to be more efficient to scramble the CRC woth the UE Identity, which saves the payload but at the cost of a small increase in the probability of false detection of a PDCCH intended for another UE.

K Labs S.r.l. all right reserved

Cap 5 - pag. 26

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 27

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 28

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 29

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 30

LTE Architecture and Air Interface

PDCCH (i.e. DCI) allocates resources to the UE for receiving the PDSCH. There are three types of allocation mechanisms varying from a simple bitmap (type 0) through the most complex (type 2), which also has the most flexibility.

K Labs S.r.l. all right reserved

Cap 2 - pag. 31

LTE MAC, RLC and PDCP

The UE is required to monitor the downlink for the presence of the PDCCH. The PCFICH indicates the number of PDCCH symbols (1, 2, or 3) in each sub-frame to monitor and the PHICH symbol duration, which is read from the P-BCH. The PHICH duration is less than or equal to the number of PDCCH symbols and is 1 or 3 for unicast operation, and 1 or 2 for MBSFN operation.

K Labs S.r.l. all right reserved

Cap 5 - pag. 32

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 33

LTE MAC, RLC and PDCP

An RLC entity can be configured to perform data transfer in one of the following three modes: Transparent Mode (TM), Unacknowledged Mode (UM) or Acknowledged Mode (AM). Consequently, an RLC entity is categorized as a TM RLC entity, an UM RLC entity or an AM RLC entity depending on the mode of data transfer that the RLC entity is configured to provide. A TM RLC entity is configured either as a transmitting TM RLC entity or a receiving TM RLC entity. The transmitting TM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs to its peer receiving TM RLC entity via lower layers. The receiving TM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer transmitting TM RLC entity via lower layers. An UM RLC entity is configured either as a transmitting UM RLC entity or a receiving UM RLC entity. The transmitting UM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs to its peer receiving UM RLC entity via lower layers. The receiving UM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer transmitting UM RLC entity via lower layers. An AM RLC entity consists of a transmitting side and a receiving side. The transmitting side of an AM RLC entity receives RLC SDUs from upper layer and sends RLC PDUs to its peer AM RLC entity via lower layers. The receiving side of an AM RLC entity delivers RLC SDUs to upper layer and receives RLC PDUs from its peer AM RLC entity via lower layers.

K Labs S.r.l. all right reserved

Cap 5 - pag. 34

LTE MAC, RLC and PDCP

A general classification of logical channels is into two groups: - Control Channels (for the transfer of control plane information); - Traffic Channels (for the transfer of user plane information). There is one MAC entity per cell. Transparent Mode is only applied to BCCH, CCCH and PCCH. Control channels are used for transfer of control plane information only. The control channels offered by MAC are: Broadcast Control Channel (BCCH) A DL channel for broadcasting system control information. Paging Control Channel (PCCH) A DL channel that transfers paging information and system information change notifications. This channel is used for paging when the network does not know the location cell of the UE. Common Control Channel (CCCH) Channel for transmitting control information between UEs and network. This channel is used for UEs having no RRC connection with the network. Multicast Control Channel (MCCH) A p-t-mp DL channel used for transmitting MBMS control information from the network to the UE, for one or several MTCHs. This channel is only used by UEs that receive MBMS. Dedicated Control Channel (DCCH) A p-t-p bi-directional channel that transmits dedicated control information between a UE and the network. Used by UEs having an RRC connection. Traffic channels are used for the transfer of user plane information only. The traffic channels offered by MAC are: Dedicated Traffic Channel (DTCH) A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user information. A DTCH can exist in both uplink and DL. Multicast Traffic Channel (MTCH) A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE. This channel is only used by UEs that receive MBMS.
K Labs S.r.l. all right reserved

Cap 5 - pag. 35

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 36

LTE MAC, RLC and PDCP

A TM RLC entity delivers/receives the following RLC data PDU: -TMD PDU

When a transmitting TM RLC entity forms TMD PDUs from RLC SDUs, it shall: -not segment nor concatenate the RLC SDUs; -not include any RLC headers in the TMD PDUs.
When a receiving TM RLC entity receives TMD PDUs, it shall: -deliver the TMD PDUs (which are just RLC SDUs) to upper layer.

K Labs S.r.l. all right reserved

Cap 5 - pag. 37

LTE MAC, RLC and PDCP

An UM RLC entity delivers/receives the following RLC data PDU: -UMD PDU. When a transmitting UM RLC entity forms UMD PDUs from RLC SDUs, it shall: -segment and/or concatenate the RLC SDUs so that the UMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer; -include relevant RLC headers in the UMD PDU. When a receiving UM RLC entity receives UMD PDUs, it shall: -detect whether or not the UMD PDUs have been received in duplication, and discard duplicated UMD PDUs; -reorder the UMD PDUs if they are received out of sequence; -detect the loss of UMD PDUs at lower layers and avoid excessive reordering delays; -reassemble RLC SDUs from the reordered UMD PDUs (not accounting for RLC PDUs for which losses have been detected) and deliver the RLC SDUs to upper layer in ascending order of the RLC SN; -discard received UMD PDUs that cannot be re-assembled into a RLC SDU due to loss at lower layers of an UMD PDU which belonged to the particular RLC SDU. At the time of RLC re-establishment, the receiving UM RLC entity shall: -if possible, reassemble RLC SDUs from the UMD PDUs that are received out of sequence and deliver them to upper layer; -discard any remaining UMD PDUs that could not be reassembled into RLC SDUs; -initialize relevant state variables and stop relevant timers.

K Labs S.r.l. all right reserved

Cap 5 - pag. 38

LTE MAC, RLC and PDCP

An AM RLC entity delivers/receives the following RLC data PDUs: -AMD PDU; -AMD PDU segment. An AM RLC entity delivers/receives the following RLC control PDU: -STATUS PDU. When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall: -segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer. -The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ): -if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the RLC data PDU into AMD PDU segments; -the number of re-segmentation is not limited. -When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or AMD PDU segments from RLC data PDUs to be retransmitted, it shall: include relevant RLC headers in the RLC data PDU. When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: -detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data PDUs; -reorder the RLC data PDUs if they are received out of sequence; -detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity; -reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in sequence. At the time of RLC re-establishment, the receiving side of an AM RLC entity shall: -if possible, reassemble RLC SDUs from the RLC data PDUs that are received out of sequence and deliver them to upper layer; -discard any remaining RLC data PDUs that could not be reassembled into RLC SDUs; -initialize relevant state variables and stop relevant timers.

K Labs S.r.l. all right reserved

Cap 5 - pag. 39

LTE MAC, RLC and PDCP

-The PDU sequence number carried by the RLC header is independent of the SDU sequence number (i.e. PDCP sequence number); -A red dotted line indicates the occurrence of segmentation; -Because segmentation only occurs when needed and concatenation is done in sequence, the content of an RLC PDU can generally be described by the following relations: -{0; 1} last segment of SDUi + [0; n] complete SDUs + {0; 1} first segment of SDUi+n+1 ; or -1 segment of SDUi .

K Labs S.r.l. all right reserved

Cap 5 - pag. 40

LTE MAC, RLC and PDCP

Each RB (i.e. DRB and SRB, except for SRB0) is associated with one PDCP entity. Each PDCP entity is associated with one or two (one for each direction) RLC entities depending on the RB characteristic (i.e. unidirectional or bi-directional) and RLC mode. The PDCP entities are located in the PDCP sublayer. The PDCP sublayer is configured by upper layers The PDCP entities are located in the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP entity carrying user plane data may be configured to use header compression. Each PDCP entity is carrying the data of one radio bearer. In this version of the specification, only the robust header compression protocol (ROHC), is supported. Every PDCP entity uses at most one ROHC instance. A PDCP entity is associated either to the control plane or the user plane depending on which radio bearer it is carrying data for. Figure represents the functional view of the PDCP entity for the PDCP sublayer; it should not restrict implementation. The figure is based on the radio interface protocol architecture.

K Labs S.r.l. all right reserved

Cap 5 - pag. 41

LTE MAC, RLC and PDCP

- PDCP PDU and PDCP header are octet-aligned; -PDCP header can be either 1 or 2 bytes long.

NOTE: When compared to UTRAN, the lossless DL RLC PDU size change is not required.

K Labs S.r.l. all right reserved

Cap 5 - pag. 42

LTE MAC, RLC and PDCP

The header compression protocol generates two types of output packets: - compressed packets, each associated with one PDCP SDU - standalone packets not associated with a PDCP SDU, i.e. interspersed ROHC feedback packets A compressed packet is associated with the same PDCP SN and COUNT value as the related PDCP SDU. Interspersed ROHC feedback packets are not associated with a PDCP SDU. They are not associated with a PDCP SN and are not ciphered.

K Labs S.r.l. all right reserved

Cap 5 - pag. 43

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 44

LTE MAC, RLC and PDCP

K Labs S.r.l. all right reserved

Cap 5 - pag. 45

LTE MAC, RLC and PDCP

The table describes the possible combinations of physical channels that can be sent in parallel in the uplink in the same TTI by one UE.

K Labs S.r.l. all right reserved

Cap 5 - pag. 46

LTE MAC, RLC and PDCP

The table describes the possible combinations of physical channels that can be received in parallel in the downlink in the same TTI by one UE.
Note 1: Note 2: Note 3: Note 4: Note 5: Note 6: Note 7: PDCCH is used to convey PDCCH order for Random Access. For TDD UL/DL configuration 0, two PDCCHs can be received in the same subframe for UL-SCH in two different uplink subframes. RA-RNTI and Temporary C-RNTI are mutually exclusive and only applicable during Random Access procedure. Temporary C-RNTI is only applicable when no valid C-RNTI is available. Temporary C-RNTI is only applicable during contention-based Random Access procedure. Semi-Persistent Scheduling C-RNTI is used for DL Semi-Persistent Scheduling release Semi-Persistent Scheduling C-RNTI is used for UL Semi-Persistent Scheduling release

K Labs S.r.l. all right reserved

Cap 5 - pag. 47