03 RA41233EN06GLA1 Uu Layer 2 Operation

RA41233EN06GLA1

Uu Layer 2 Operation

1

RA41233EN06GLA1


2

RA41233EN06GLA1


4

RA41233EN06GLA1


5

RA41233EN06GLA1


6

For the Uu (air) interface, LTE divides the Data Link Layer into the following sublayers:

• Radio Resource Control (RRC)

• Packet Data Convergence Protocol (PDCP)

• Radio Link Control (RLC)

• Medium Access Control (MAC)

RA41233EN06GLA1


7

The RRC Sub layer is responsible for broadcast of system information, RRC connection and configuration control, paging, initial security activation, mobility and handovers, recovery from radio link failure and generic protocol error handling, measurement configuration and reporting, and MBMS scheduling. RRC connection and configuration control includes setting up Radio Bearer (RB) channels carrying user data, QoS configuration, and error recovery (ARQ and HARQ) configuration. 3GPP TS 36.331 Radio Resource Control (RRC) Protocol Specification

RA41233EN06GLA1


8

The Packet Data Convergence Protocol (PDCP) Sub layer is responsible for transferring RRC signaling or user data, compressing data packet headers, timer-based packet discards, and encrypting packets.

For signaling packets, the PDCP Sub layer also checks message integrity.

3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) Specification

RA41233EN06GLA1


9

The Radio Link Control (RLC) Sub layer segments large packets and concatenates small packets for handling by the MAC Sub layer and Physical Layer. RLC supports acknowledged, unacknowledged, and transparent mode operation. In addition, the RLC Sub layer performs Automatic Repeat Request (ARQ) error recovery for data packets. ARQ is a retransmission error recovery technique.

3GPP TS 36.322 Radio Link Control (RLC) Protocol Specification

RA41233EN06GLA1


10

The Medium Access Control (MAC) Sub layer performs dynamic scheduling of Physical Layer resources, and maps data and control traffic to and from the Physical Layer. The MAC Sub layer multiplexes RLC packets into a single MAC PDU for transmission by the Physical Layer. In addition, the MAC Sub layer performs Hybrid ARQ (HARQ) error recovery. Like ARQ, HARQ is a retransmission error recovery technique. 3GPP TS 36.321 Medium Access Control (MAC) Protocol Specification

RA41233EN06GLA1


11

the Uu Physical Layer applies FEC encoding, modulates bits, and maps the modulated signals into physical frames and subframes. In addition, the Physical Layer calculates and attaches a 24-bit Cyclic Redundancy Check (CRC) to the end of the MAC PDU before scrambling and modulating the packet.

RA41233EN06GLA1


12

The PDCP, RLC, and MAC Sublayers, as well as the Physical Layer, act as service access points. A Service Access Point (SAP) provides service to the layer or sub layer above. A SAP receives a Service Data Unit (SDU) from the layer above. After processing the SDU, a service access point delivers a Protocol Data Unit (PDU) for the layer below. A PDU typically includes the processed SDU, and one or more headers inserted by the service access point.

RA41233EN06GLA1


13

The graphic shows a data message progressing though the Uu Data Link sublayers.

Step

1. An upper layer data message is received at the PDCP Sub layer. PDCP may compress the IP data packet headers, and encrypt the resulting compressed packet.

2. After attaching a PDCP header to the data, the PDCP Sub layer passes the data packet to the RLC Sub layer.

3. The RLC Sub layer segments or concatenates PDCP packets as needed, and adds an RLC header. An RLC packet may contain more than one PDCP packet or segment.

4. The MAC Sub layer adds a MAC subheader for each MAC packet. The MAC subheader contains a logical connection ID and length field for each MAC packet. The resulting MAC packet is passed to the Physical Layer for encoding, modulation, and transmission within a DL or UL subframe.

RA41233EN06GLA1


14

RA41233EN06GLA1


15

The Radio Resource Control (RRC) layer sets up and manages the Uu air interface between the UE and eNodeB, and transports Non-Access Stratum (NAS) messages between the UE and MME. •Broadcast of system information.

− Including NAS common information. − Information applicable for UEs in RRC_IDLE, e.g. cell (re-)selection parameters, neighboring cell

information and information (also) applicable for UEs in RRC_CONNECTED, e.g. common channel configuration information.

•RRC connection control. − Paging. − Establishment/ modification/ release of RRC connection, including e.g. assignment/ modification of UE

identity (C-RNTI), establishment/ modification/ release of SRB1 and SRB2, access class barring. − Initial security activation, i.e. initial configuration of AS integrity protection (SRBs) and AS ciphering

(SRBs, DRBs). − RRC connection mobility including e.g. intra-frequency and inter-frequency handover, associated

security handling, i.e. key/ algorithm change, specification of RRC context information transferred between network nodes.

− Establishment/ modification/ release of RBs carrying user data (DRBs). − Radio configuration control including e.g. assignment/ modification of ARQ configuration, HARQ

configuration, DRX configuration. − QoS control including assignment/ modification of semi-persistent scheduling (SPS) configuration

information for DL and UL, assignment/ modification of parameters for UL rate control in the UE, i.e. allocation of a priority and a prioritized bit rate (PBR) for each RB.

− Recovery from radio link failure. •Inter-RAT mobility including e.g. security activation, transfer of RRC context information. •Measurement configuration and reporting.

− Establishment/ modification/ release of measurements (e.g. intra-frequency, inter-frequency and inter- RAT measurements).

− Setup and release of measurement gaps. − Measurement reporting.

•Other functions including e.g. transfer of dedicated NAS information. •Generic protocol error handling. •Support of self-configuration and self-optimization.

RA41233EN06GLA1


16

In general, RRC signaling covers the following procedures

System information

Includes broadcasting of system information (scheduling and notification of

changes), system information acquisition and acquisition of SI messages.

Connection control

Includes paging, RRC connection establishment, initial security activation

RRC connection reconfiguration, counter check, RRC connection re-

establishment, RRC connection release, radio resource configuration and

radio link failure actions.

Measurement

Includes measurement configuration, Layer 3 filtering and measurement

reporting.

Inter-RAT mobility

Includes handover to E-UTRA, mobility from E-UTRA and inter-RAT cell

change.

Other

Includes DL/UL information transfer and UE capability transfer.

RA41233EN06GLA1


17

RA41233EN06GLA1


18

RA41233EN06GLA1


19

RA41233EN06GLA1


20

RA41233EN06GLA1


21

RA41233EN06GLA1


22

RA41233EN06GLA1


23

RA41233EN06GLA1


24

RRC connection establishment involves the establishment of SRB1. E-UTRAN completes RRC connection establishment prior to completing the establishment of the S1 connection, i.e. prior to receiving the UE context information from the EPC. Consequently, AS security is not activated during the initial phase of the RRC connection. During this initial phase of the RRC connection, the E-UTRAN may configure the UE to perform measurement reporting. However, the UE only accepts a handover message when security has been activated.

Upon receiving the UE context from the EPC, E-UTRAN activates security (both ciphering and integrity protection) using the initial security activation procedure. The RRC messages to activate security (command and successful response) are integrity protected, while ciphering is started only after completion of the procedure. That is, the response to the message used to activate security is not ciphered, while the subsequent messages (e.g. used to establish SRB2 and DRBs) are both integrity protected and ciphered.

After having initiated the initial security activation procedure, E-UTRAN initiates the establishment of SRB2 and DRBs, i.e. E-UTRAN may do this prior to receiving the confirmation of the initial security activation from the UE. In any case, E-UTRAN will apply both ciphering and integrity protection for the RRC connection reconfiguration messages used to establish SRB2 and DRBs. E-UTRAN should release the RRC connection if the initial security activation and/ or the radio bearer establishment fails (i.e. security activation and DRB establishment are triggered by a joint S1-procedure, which does not support partial success).

For SRB2 and DRBs, security is always activated from the start, i.e. the E-UTRAN does not establish these bearers prior to activating security.

RA41233EN06GLA1


25

Access Stratum (AS) security comprises of the integrity protection of RRC

signaling (SRBs) as well as the ciphering of RRC signaling (SRBs) and user

data (DRBs).

The integrity protection algorithm is common for signaling radio bearers SRB1

and SRB2. The ciphering algorithm is common for all radio bearers (i.e.

SRB1, SRB2 and DRBs). Neither integrity protection nor ciphering applies for

SRB0.

RRC integrity and ciphering are always activated together, i.e. in one

message/ procedure. RRC integrity and ciphering are never de-activated.

However, it is possible to switch to a 'NULL' ciphering algorithm (eea0).

RA41233EN06GLA1


26

RA41233EN06GLA1


27

With this procedure, the UE is requested to check if, for each DRB, the most

significant bits of the COUNT match with the values indicated by E-UTRAN

RA41233EN06GLA1


28

The purpose of this procedure is to re-establish the RRC connection, which

involves the resumption of SRB1 operation and the re-activation of security.

A UE in RRC_CONNECTED, for which security has been activated, may

initiate the procedure in order to continue the RRC connection. The

connection re-establishment succeeds only if the concerned cell is prepared

i.e. has a valid UE context. In case E-UTRAN accepts the re-establishment,

SRB1 operation resumes while the operation of other radio bearers remains

suspended. If AS security has not been activated, the UE does not initiate the

procedure but instead moves to RRC_IDLE directly

RA41233EN06GLA1


29

RA41233EN06GLA1


30

The RRC protocol is responsible for the basic configuration of the radio

protocol stack. But note that some radio management functions (scheduling,

physical resource assignment for physical channels) are handled by layer 1

and layer 2 autonomously.

MAC and layer 1 signaling has usually delays that are within 10 ms, whereas

RRC signaling usually takes something around 100 ms and more to complete

an operation.

RA41233EN06GLA1


31

RA41233EN06GLA1


32

RA41233EN06GLA1


33

RA41233EN06GLA1


34

RA41233EN06GLA1


35

RA41233EN06GLA1


36

RA41233EN06GLA1


37

RA41233EN06GLA1


38

Signaling Radio Bearers (SRBs) are Radio Bearers used to transmit RRC and NAS (signaling) messages. -SRB0 is for RRC messages using the common control (CCCH) logical channel, while SRB1 and SRB2 carry RRC and NAS messages over a dedicated control (DCCH) logical channel. SRB2 has a lower-priority than SRB1 and is always configured after security activation. Once security is activated, all RRC messages are integrity protected and ciphered by PDCP. In addition, the UE and MME independently perform integrity protection and ciphering for the NAS messages.

RA41233EN06GLA1


39

RA41233EN06GLA1


40

The PDCP Sub layer provides services to signaling radio bearers (RRC control packets) or data radio bearers (IP data bearer packets). A separate PDCP entity is associated with each signaling or data radio bearer. The PDCP Sub layer encrypts/decrypts data and control packets, compresses/decompresses data packet headers, and checks control packets for message integrity. The PDCP Sub layer supports two control messages: PDCP Status Report and ROHC Feedback Report. 3GPP TS 36.323 Packet Data Convergence Protocol (PDCP) Specification IETF RFC 3095 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed IETF RFC 3843 RObust Header Compression (ROHC): A Compression Profile for IP IETF RFC 4815 RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095 IETF RFC 4995 The RObust Header Compression (ROHC) Framework IETF RFC 4996 RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP) IETF RFC 5225 RObust Header Compression (ROHC) Version 2: Profiles for RTP, UDP, IP, ESP and UDP Lite

RA41233EN06GLA1


41

RA41233EN06GLA1


42

A ROHC compressor is in one of three states: Initialization and Refresh, First Order, and Second Order.

Initialization and Refresh (IR) state occurs when the compressor has just been created or reset. In IR state, full (uncompressed) packet headers are sent.

In First-Order state, the compressor has detected and stored static fields such as IP addresses and port numbers. The compressor also sends dynamic packet field differences. This state compresses all static fields and some dynamic fields.

In Second-Order state, the compressor suppresses all dynamic fields such as RTP sequence numbers. In this state, the transmitter sends a logical sequence number and partial checksum, which the receiver uses to predict the dynamic fields of the next expected packet. This state compresses all static fields and all dynamic fields.

If compression or decompression failures are detected, the compressors will revert to IR state.

RA41233EN06GLA1


43

Header compression profiles describe the rules for ROHC compression. If used, header compression will reduce the combined IPv4 + UDP + RTP header size from 40 bytes to 2-4 bytes.

RA41233EN06GLA1


44

The specific ROHC profile to use for a given data radio bearer is configured using RRC signaling.

Profiles 101-104 are defined using ROHC v2 which introduces several improvements over ROHC v1.

RA41233EN06GLA1


45

RA41233EN06GLA1


46

3GPP TS 36.322 Radio Link Control (RLC) Protocol Specification

RA41233EN06GLA1


47

The RLC Sub layer receives a PDCP PDU (RLC SDU) from the PDCP Sub layer. After processing the packet, an RLC header is attached to the front of the packet.

RA41233EN06GLA1


48

The RLC Sub layer must prepare a PDU that fills the Physical Layer grant. The graphic illustrates this process for the uplink.

The eNodeB “advertises” an UL grant for the UE in the PDCCH channel. The UL grant is described using a modulation scheme and some number of resource blocks.

The MAC Sub layer calculates the number of bits/bytes represented by the grant and reports the scheduled bandwidth to the RLC Sub layer as the Transport Block (TB) size. Using concatenation and segmenting, the RLC Sub layer builds a PDU that fills the “advertised” TB size.

The MAC Sub layer may support multiple RLC Sublayers. When serving different RLC stacks, the MAC Sub layer must balance QoS requirements and data already buffered for transport.

RA41233EN06GLA1


49

In AM and UM modes, the RLC Sub layer segments and concatenates PDCP packets to form RLC PDUs. How large an RLC PDU is allowed, e.g. when should a packet be segmented?

Based on dynamic grants or allocations, the MAC Sub layer determines the allowed TB size and passes that information to the RLC Sub layer. The RLC Sub layer uses the TB size as it processes the PDCP packets.

RA41233EN06GLA1


50

RA41233EN06GLA1


51

RA41233EN06GLA1


52

RA41233EN06GLA1


53

RA41233EN06GLA1


54

RLC Status PDU Fields

• Data/Control (D/C) Indicator – 0 indicates this is a control packet.

• Control PDU Type (CPT) – This 3-bit field indicates the type of RLC control packet. The Status PDU has a type value of 000; all other values are currently reserved.

• ACK_SN – Indicates the 10-bit sequence number of the next RLC data PDU to be received. The receiver interprets that all data PDUs up to but not including the ACK_SN have been correctly received by its RLC peer, excluding any PDUs indicated with NACK_SN.

• E1 BIt – Indicates if a set of NACK_SN, E1, and E2 fields does (1) or does not (0) follow.

• NACK_SN – Indicates the 10-bit sequence number of the RLC data PDU that has been detected as lost by the receiver.

• E2 Bit – Indicates if a set of SOstart and SOend fields does (1) or does not (0) follow.

• Segment Offset Start (SOstart) – This 15-bit field indicates the beginning data byte number of the missing segment of the message identified by NACK-SN.

• Segment Offset End (SOend) – This 15-bit field indicates the ending data byte number of the missing segment of the message identified by NACK-SN. If the SOend value is set to all 1 bits, the missing portion extends from the SOstart to the last byte of the data PDU.

RA41233EN06GLA1


55

As part of its traffic scheduling responsibility, the MAC Sub layer passes a Transport Block to the RLC Sub layer describing the current transport capability for a logical connection. The RLC Sub layer may concatenate (join together) more than one data element into a single RLC PDU to take full advantage of the transport capability.

The graphic shows three data elements (RLC SDUs) concatenated into one RLC PDU. The RLC header includes length fields used by the receiver to locate the separate data elements. Except for the last data element, each concatenated data element has an associated length field in the RLC header.

The concatenated SDUs must be associated with the same logical channel. The MAC Sub layer attaches a subheader with a (single) logical channel ID to the RLC PDU.

RA41233EN06GLA1


56

In addition to the fields already described, a concatenated PDU also contains additional Extension Bits and Length Indicator fields.

• Length Indicator (LI) Field – 11-bit field that indicates the length in bytes of the associated data element. An 11-bit length field allows values up to 2047.

Octet 1

• E = 1 indicates additional fields follow the Sequence Number.

Octet 3

• E = 1 indicates an additional E Bit and LI field follow the LI-1 field.

• LI-1 contains the length in bytes of the first data element (PDCP PDU 1).

Octet 4-5

• E = 0 indicates the data field follows the LI-2 field.

• LI-2 contains the length in bytes of the second data element (PDCP PDU 2).

The graphic shows an Acknowledged Mode (AM) RLC PDU with three data elements. Exactly the same Bit and Length Indicator fields are used with Unacknowledged Mode (UM).

RA41233EN06GLA1


57

If necessary, the RLC Sub layer may segment (break apart) large data packets. Each segment is transmitted in a separate RLC PDU. The RLC header describes how to rebuild the original data packet using the Segment Offset and Last Segment Flag fields.

A large PDU may be broken into many segments. Every PDU segment shares the same sequence number.

RA41233EN06GLA1


58

In addition to the fields already described, a segment header also contains the following fields:

• Last Segment Flag (LSF) – 1 indicates this is the last segment of a data packet; 0 indicates this is a first or middle segment.

• Segment Offset (SO) – Indicates the position in the original data packet associated with the first data byte of this segment.

Octet 1

• E = 1 indicates additional fields follow the Sequence Number.

• RF = 1 indicates the data field contains a segment.

• FI = 01 indicates the first data byte is associated with the beginning of an SDU, while the last data byte is not associated with the end of an SDU.

Octets 3-4

• LSF = 0 indicates this is not the last segment of an SDU.

• Segment Offset indicates the SDU offset position of the first data byte of this segment.

An RLC PDU may contain a segment and complete SDU. In that case, the RLC header includes a length field for each data element except the last.

RA41233EN06GLA1


59

RA41233EN06GLA1


60

Error handling and recovery occurs on many layers and sublayers. The LTE Physical Layer uses Forward Error Correction (FEC) overhead to recover from bit errors introduced by the air interface.

The LTE Layer 2 offers two error recovery techniques: ARQ and HARQ. Hybrid Automatic Repeat Request (HARQ) offers quick, interval-based ACKs/NACKs with retransmissions. Automatic Repeat Request (ARQ) offers slower, sequence number based ACKs/NACKs with retransmissions.

At Layer 4, both TCP and SCTP perform error recovery and retransmission.

Layer 5 offers several possible error recovery techniques. For applications that run on top of UDP, the application protocol may offer sequence number and/or timer-based retransmission. Voice and video traffic may use interpolation, prediction, or erasure error recovery techniques

Note that the error recovery time-out period increases as you move up the protocol stack. From a delay perspective, we want to recover from error conditions at the lowest layer possible

RA41233EN06GLA1


61

1. The RLC transmitter sends AM data, sequence number 1. The Polling bit is set to 1, ordering the receiver to return an RLC Status message.

2. The RLC receiver returns a Status message with the ACK_SN set to2. ACK_SN 2 indicates data message 1 was correctly received; the next expected sequence number is 2.

3. The RLC transmitter sends Acknowledged Mode data, sequence number 2 with the Polling bit = 1. This message was lost or corrupted during transmission.

4. The RLC transmitter sends AM data, sequence number 3 with the Polling bit = 1.

5. The RLC receiver returns a Status message with the ACK_SN=4 and NACK_SN=2. ACK_SN 4 indicates data message 3 was correctly received; the next expected sequence number is 4. However, NACK_SN=2 orders the transmitter to resend message 2.

6. The RLC transmitter resends data message 2 with the Polling bit = 1.

7. The RLC receiver returns a Status message with the ACK_SN set to 4 indicating all data messages up to (but not including) 4 were correctly received.

The RLC Sub layer only supports ARQ for AM data packets.

RA41233EN06GLA1


62

RA41233EN06GLA1


63

3GPP TS 36.321 Medium Access Control (MAC) Protocol

Specification

RA41233EN06GLA1


64

RA41233EN06GLA1


65

The MAC Sub layer receives an RLC PDU (MAC SDU) from the RLC Sub layer. After processing the packet, an MAC subheader is attached to the front of the packet. The MAC packet may contain more than one RLC PDU and MAC subheader.

RA41233EN06GLA1


66

The MAC Sub layer creates a MAC subheader for each RLC PDU. MAC subheaders contain the following fields: • Reserved Bits – Reserved bits have no meaning; each reserved bit is set to 0. • Extension Bit – 1 indicates more subheader bytes or more subheaders follow; 0

indicates last or only subheader. • Logical Channel ID (LCID) – 5-bit field that identifies the logical channel for the

associated packet. • Format Bit – 0 indicates the Length field is 7-bits long; 1 indicates the Length field

is 15-bits long. • Length Field – 7-bit or 15-bit field that indicates the length in bytes of the

associated packet. A 7-bit length field allows values up to 127; a 15-bit length field allows values up to 32,767.

RA41233EN06GLA1


67

Several RLC PDUs may be multiplexed together in a single MAC PDU. Each RLC PDU will have its own MAC subheader. The Length field indicates the size (and relative position) of each component of the MAC PDU. • 1-Octet MAC Subheader – A MAC subheader without a Length field is associated

with the last or only RLC PDU in the MAC PDU. This subheader format is also used for known fixed-length MAC components.

• 2-Octet MAC Subheader – A MAC subheader with a 7-bit Length field (F bit=0). This format is used with an RLC PDU up to 127 bytes long, which is not the last component in the MAC PDU.

• 3-Octet MAC Subheader – A MAC subheader with a 15-bit Length field (F bit=1). This format is used with an RLC PDU greater than 127 bytes long, which is not the last component in the MAC PDU.

RA41233EN06GLA1


68

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or the type of the corresponding MAC control element or padding as described in table for the DL-SCH and UL-SCH. There is one LCID field for each MAC SDU, MAC control element or padding included in the MAC PDU. In addition to that, one or two additional LCID fields are included in the MAC PDU, when single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU. The LCID field size is 5 bits.

RA41233EN06GLA1


69

RA41233EN06GLA1


70

The following MAC Control Elements are defined:

• Buffer Status Report (BSR) – Sent by UE to describe the number of bytes of data ready for UL transport

• C-RNTI – Sent by UE to identify the sending UE and traffic flow

• DRX Command – Sent by eNodeB to trigger discontinuous reception in the UE

• Power Headroom Report – Sent by UE to indicate the difference (headroom) between its current power output and its maximum power output

• Timing Advance (TA) – Sent by eNodeB to adjust UE timing in .5 μs increments

• UE Contention Resolution ID – Sent by eNodeB to resolve UE contention on the PRACH

• Backoff Indicator (BI) – Sent by the eNodeB to indicate an overload condition

• Random Access Response (RAR) – Sent by the eNodeB in response to a Random Access Preamble

RA41233EN06GLA1


71

The graphic shows the MAC multiplexing process. In this example, three RLC PDUs will be multiplexed into one MAC PDU. A separate MAC subheader is created for each RLC PDU. The MAC subheaders for RLC PDU 1 and 2 must contain Length fields; the MAC subheader for PDU 3 will not include a Length field (last PDU).

The MAC PDU begins with all of the MAC subheaders, followed by the component RLC PDUs in exactly the same order as the MAC subheaders.

The MAC Sub layer can multiplex RLC PDUs together. However it cannot segment or reassemble RLC PDUs. Only the RLC Sub layer may segment packets

RA41233EN06GLA1


72

The graphic shows a MAC PDU with Control Elements and an RLC PDU. A Control Element is a special MAC “signaling message” used for Random Access Responses, UE buffer status reporting, and so on. Control Elements are placed before RLC PDUs in the MAC payload.

Each MAC Control Element has its own MAC subheader

RA41233EN06GLA1


73

RA41233EN06GLA1


74

The Random Access Procedure is used by the UE to access the network when it does not have a dedicated signaling channel. Random access is used for:

• Initial Access from RRC-IDLE – initial attachment/registration upon power-up, Tracking Area Updates, UE attempting to set-up a data session, UE answering a page or session request.

• Handover – the UE must perform a Random Access Procedure with the new target cell before resuming service.

• UL/DL data arrival in RRC-CONNECTED – UE may lose synchronization with the network OR there are no scheduled resources for the for data transmission in the uplink.

The standard also defines two different types of Random Access Procedures:

• Contention-based – the UE transmits any valid RA Preamble ID for the cell. Other UEs may use the same RA Preamble ID. This is used mainly in the Initial Access described above.

• Non-contention-based – the eNodeB assigns a specific RA Preamble ID to the UE. This procedure is used in handovers and resumption of downlink data transmission while the UE is in RRC-CONNECTED mode.

RA41233EN06GLA1


75

RA41233EN06GLA1


76

RAR/BI MAC Header Fields • E Bit – A 1-bit field indicating more RAR headers are present (1), or not present (0). • Type (T) Bit – A 1-bit field indicating the RAR subheader format. T is set to 1 to

indicate a Random Access ID, or 0 to indicate a Backoff Indicator. If T=1, a Random Access Response field is present after the MAC subheader.

• Random Access Preamble ID (RAPID) – A 6-bit field identifying the transmitted Random Access Preamble.

• R Bit – Reserved bit, set to 0.

RA41233EN06GLA1


77

• Backoff Indicator (BI) – A 4-bit field describing the overload condition in the cell. The UE must wait n milliseconds before attempting random access again.

RA41233EN06GLA1


78

• Timing Advance (TA) – An 11-bit field indicating the required adjustment to the UL transmission timing for timing synchronization. The timing adjustment units are .5 μs.

• UL Grant – A 20-bit field indicating the UL resources granted to the UE. The subfields are described on the next page.

• Temporary C-RNTI – A 16-bit field indicating the temporary identity used by the UE during random access operation.

RA41233EN06GLA1


79

The 20-bit UL Grant contains the following subfields:

• Hopping Flag Bit – If set to 1, the UE must perform PUSCH frequency hopping.

• Resource Block Assignment – A 10-bit field that indicates the number of resource blocks allocated for the UL grant.

• Truncated Modulation and Coding Scheme – A 4-bit field that identifies the MCS required for the UL grant.

• TPC command for scheduled PUSCH – A 3-bit field that indicates the required power setting for the PUSCH channel.

• UL Delay Bit – If set to 0, UL Delay indicates the UL grant will occur in the next available subframe. If set to 1, the UL must postpone the UL PUSCH transmission to the first available opportunity after the next available subframe.

• CQI Request Bit – If set to 1, the UE must perform CQI reporting using the PUSCH channel.

RA41233EN06GLA1


80

RA41233EN06GLA1


81

• Hybrid ARQ is an interval-based error recovery technique

• A MAC PDU transmitter must receive an HARQ ACK before transmitting the next MAC PDU

• For FDD, the HARQ ACK or NACK occurs 4 subframes after the beginning of a MAC PDU

RA41233EN06GLA1


82

RA41233EN06GLA1


83

RA41233EN06GLA1


84

The eNodeB describes both DL and UL scheduling in the Physical Downlink

Control Channel (PDCCH). Each DL allocation or UL grant contains the following information:

• UE’s C-RNTI

• Starting resource block within the DL or UL subframe

• Number of resource blocks in the allocation or grant

• Modulation scheme selected by the eNodeB

DL Allocation

The UE must detect its C-RNTI in the PDCCH and interpret the MAC PDU in the DL allocation. Remember, the MAC PDU contains a shared Logical Channel ID; the C-RNTI describes the specific UE for this packet

UL Grant

The UE must completely fill the bandwidth grant, inserting padding if necessary

RA41233EN06GLA1


85

LTE relies on temporary identities for UE scheduling and operation. The manufacturer assigns a static International Mobile Equipment ID (IMEI) to each UE type. The service provider assigns a static International Mobile Subscriber ID (IMSI) to each subscriber UE (USIM card). The P-GW dynamically assigns an IP address to the UE during network entry and registration. However, the eNodeB assigns a 2-byte temporary ID called the Cell Radio Network Temporary ID (C-RNTI) to the UE for scheduling UL bandwidth grants and DL allocations.

RA41233EN06GLA1


86

The values corresponding to the RA-RNTI values of a cell’s PRACH configuration are not used in the cell for any other RNTI (C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPCPUCCH- RNTI or TPC-PUSCH-RNTI).

A UE uses the same C-RNTI on all Serving Cells(LTE_A).

RA41233EN06GLA1


87

RA41233EN06GLA1


88

1. The UE sends a contention-based or non-contention-based Random Access Preamble on the PRACH

2. If successfully received, the eNodeB returns a Random Access Response (RAR) on the PDSCH. The RAR contains an UL grant and a Temporary C-RNTI.

3. The UE uses the UL grant to send a Scheduling Request on the PUCCH.

4. The eNodeB schedules an UL resource allocation and notifies the UE using the PDCCH.

5. The UE uses the UL grant to send a MAC data packet on the PUSCH.

RA41233EN06GLA1


89

1. The eNodeB sends a semi-persistent UL grant to the UE.

2. The UE uses the UL grant to send data packet 1. The MAC PDU will contain

the Semi-Persistent Scheduling RNTI (SP-RNTI) rather than the C-RNTI.

3. N subframes later, the UE sends data packet 2 using the SP-RNTI.

4. N subframes later, the UE sends data packet 3 using the SP-RNTI.

If dynamic scheduling and semi-persistent scheduling occur in the same subframe for a UE, the dynamic scheduling has a higher priority.

RA41233EN06GLA1


90

Using the Buffer Status Report Control Element, the UE signals the amount of data in its UL buffers. The UE sends a BSR when new UL data is ready for transmission, the UE moves to another cell, or a periodic BSR timer expires. The UE may organize its logical channels into up to four groups, based on increasing priority. The UE reports on the number of bytes ready for transmission for one Logical Channel Group (short BSR), or more than one (long BSR). The graphic illustrates both formats. • Logical Channel Group ID – A 2-bit field identifying a specific group of logical

channels. • Buffer Size – A 6-bit field indicating the total amount of data available for all logical

channels of a specific Logical Channel Group. The Buffer Size includes all RLC and PDCP data, not counting the RLC and MAC headers. The Buffer Size values are listed in the table on the next page.

Only one BSR Control Element may be used in a MAC PDU.

RA41233EN06GLA1


91

RA41233EN06GLA1


92

RA41233EN06GLA1


93

RA41233EN06GLA1


94

RA41233EN06GLA1


95

RA41233EN06GLA1


96

RA41233EN06GLA1


97

Documents

03 RA41233EN06GLA1 Uu Layer 2 Operation