EXHIBIT F

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 1 of 34
3GPP TS 36.321 V8.2.0 (2008-05)

Technical Specification 

3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;

Evolved Universal Terrestrial Radio Access (E-UTRA)

Medium Access Control (MAC) protocol specification

(Release 8)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.

 

The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. 

This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.

Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 2 of 34
3GPP 

Release 8 2 3GPP TS 36.321 V8.2.0 (2008-05) 

Keywords 

UMTS, radio 

3GPP 

Postal address 

3GPP support office address 

650 Route des Lucioles - Sophia Antipolis 

Valbonne - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Internet 

http://www.3gpp.org 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 

The copyright and the foregoing restriction extend to reproduction in all media. 

© 2008, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC). 

All rights reserved. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 3 of 34
3GPP 

Release 8 3 3GPP TS 36.321 V8.2.0 (2008-05) 

Contents 

Foreword ............................................................................................................................................................ 5

1 Scope ........................................................................................................................................................ 6

2 References ................................................................................................................................................ 6

3 Definitions and abbreviations ................................................................................................................... 6

3.1 Definitions ............................................................................................................................................................. 6

3.2 Abbreviations ........................................................................................................................................................ 7

4 General ..................................................................................................................................................... 8

4.1 Introduction ........................................................................................................................................................... 8

4.2 MAC architecture .................................................................................................................................................. 8

4.2.1 MAC Entities ................................................................................................................................................... 8

4.3 Services ................................................................................................................................................................. 8

4.3.1 Services provided to upper layers ................................................................................................................... 8

4.3.2 Services expected from physical layer ............................................................................................................ 8

4.4 Functions ............................................................................................................................................................... 9

4.5 Channel structure .................................................................................................................................................. 9

4.5.1 Transport Channels ......................................................................................................................................... 9

4.5.2 Logical Channels ........................................................................................................................................... 10

4.5.3 Mapping of Transport Channels to Logical Channels .................................................................................. 10

4.5.3.1 Uplink mapping ....................................................................................................................................... 10

4.5.3.2 Downlink mapping .................................................................................................................................. 11

5 MAC procedures .................................................................................................................................... 11

5.1 Random Access procedure .................................................................................................................................. 11

5.1.1 Random Access Procedure initialization ...................................................................................................... 11

5.1.2 Random Access Resource selection .............................................................................................................. 12

5.1.3 Random Access Preamble transmission ....................................................................................................... 12

5.1.4 Random Access Response reception ............................................................................................................ 13

5.1.5 Contention Resolution ................................................................................................................................... 14

5.1.6 Completion of the Random Access procedure ............................................................................................. 15

5.2 Maintenance of Uplink Time Alignment ........................................................................................................... 15

5.3 DL-SCH data transfer ......................................................................................................................................... 16

5.3.1 DL Assignment reception ............................................................................................................................. 16

5.3.2 HARQ operation ............................................................................................................................................ 16

5.3.2.1 HARQ Entity ........................................................................................................................................... 16

5.3.2.2 HARQ process ......................................................................................................................................... 17

5.3.3 Disassembly and demultiplexing .................................................................................................................. 17

5.4 UL-SCH data transfer ......................................................................................................................................... 18

5.4.1 UL Grant reception ........................................................................................................................................ 18

5.4.2 HARQ operation ............................................................................................................................................ 18

5.4.2.1 HARQ entity ............................................................................................................................................ 18

5.4.2.2 HARQ process ......................................................................................................................................... 19

5.4.3 Multiplexing and assembly ........................................................................................................................... 20

5.4.3.1 Logical channel prioritization ................................................................................................................. 20

5.4.3.2 Multiplexing of MAC SDUs ................................................................................................................... 21

5.4.4 Scheduling Request ....................................................................................................................................... 21

5.4.5 Buffer Status Reporting ................................................................................................................................. 21

5.4.6 Power Headroom Reporting .......................................................................................................................... 22

5.5 PCH reception ..................................................................................................................................................... 22

5.6 BCH reception ..................................................................................................................................................... 23

5.7 Discontinuous Reception (DRX) ........................................................................................................................ 23

5.8 MAC reconfiguration .......................................................................................................................................... 24

5.9 MAC Reset .......................................................................................................................................................... 24

5.X Handling of unknown, unforeseen and erroneous protocol data ....................................................................... 24

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 4 of 34
3GPP 

Release 8 4 3GPP TS 36.321 V8.2.0 (2008-05) 

6 Protocol Data Units, formats and parameters ......................................................................................... 24

6.1 Protocol Data Units ............................................................................................................................................. 24

6.1.1 General ........................................................................................................................................................... 24

6.1.2 MAC PDU (DL-SCH and UL-SCH) ............................................................................................................ 24

6.1.3 MAC Control Elements ................................................................................................................................. 26

6.1.3.1 Buffer Status Report MAC Control Elements ........................................................................................ 26

6.1.3.2 C-RNTI MAC Control Element .............................................................................................................. 26

6.1.3.3 DRX Command MAC Control Element ................................................................................................. 26

6.1.3.4 UE Contention Resolution Identity MAC Control Element ................................................................... 27

6.1.3.5 Timing Advance MAC Control Element ................................................................................................ 27

6.1.3.6 Power Headroom MAC Control Element ............................................................................................... 27

6.1.4 MAC PDU (transparent MAC) ..................................................................................................................... 28

6.1.5 MAC PDU (Random Access Response) ...................................................................................................... 28

6.2 Formats and parameters ...................................................................................................................................... 29

6.2.1 MAC header for DL-SCH and UL-SCH ...................................................................................................... 29

6.2.2 MAC header for Random Access Response ................................................................................................. 30

6.2.3 MAC payload for Random Access Response ............................................................................................... 30

7 Variables and constants .......................................................................................................................... 31

7.1 RNTI values ........................................................................................................................................................ 32

7.2 Backoff Parameter values ................................................................................................................................... 32

Annex A (informative): Change history ............................................................................................... 33

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 5 of 34
3GPP 

Release 8 5 3GPP TS 36.321 V8.2.0 (2008-05) 

Foreword 

This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 

TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 

identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 

updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 6 of 34
3GPP 

Release 8 6 3GPP TS 36.321 V8.2.0 (2008-05) 

1 Scope 

The present document specifies the E-UTRA MAC protocol. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 

document. 

 References are either specific (identified by date of publication, edition number, version number, etc.) or 

non-specific. 

 For a specific reference, subsequent revisions do not apply. 

 For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 

a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 

Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TR 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Layer 

Procedures". 

[3] 3GPP TS 36.322: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control 

(RLC) protocol specification”. 

[4] 3GPP TS 36.323: “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data 

Convergence Protocol (PDCP) Specification”. 

[5] 3GPP TS 36.212: “Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and 

channel coding”. 

[6] 3GPP TS 36.214: “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; 

Measurements”. 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 

term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

Active Time: time during which the UE monitors the PDCCH for a PDCCH-subframe. Section 5.7 defines the 

conditions for which a subframe is included as part of Active Time. 

Contention Resolution Timer: Specifies the number of consecutive PDCCH-subframe(s) during which the UE shall 

monitor the PDCCH after the uplink message containing the C-RNTI MAC control element or the uplink message 

associated with UE Contention Resolution Identity submitted from higher layer is transmitted.

DRX Cycle: Specifies the periodic repetition of the On Duration followed by a possible period of inactivity (see figure 

3.1-1 below). 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 7 of 34
3GPP 

Release 8 7 3GPP TS 36.321 V8.2.0 (2008-05) 

UE shall monitor 

PDCCH

On Duration

DRX Cycle

Opportunity for DRX

Figure 3.1-1: DRX Cycle 

DRX Inactivity Timer: Specifies the number of consecutive PDCCH-subframe(s) after successfully decoding a 

PDCCH indicating an initial UL or DL user data transmission for this UE. 

DRX Retransmission Timer: Specifies the maximum number of consecutive PDCCH-subframe(s) for as soon as a DL 

retransmission is expected by the UE. 

DRX Short Cycle Timer: This parameter specifies the number of consecutive subframe(s)the UE shall follow the short 

DRX cycle after the DRX Inactivity Timer has expired. 

HARQ RTT Timer: This parameter specifies the minimum amount of subframe(s) before a DL HARQ retransmission 

is expected by the UE. 

On Duration Timer: Specifies the number of consecutive PDCCH-subframe(s) at the beginning of a DRX Cycle. 

RA-RNTI: The Random Access RNTI is used on the PDCCH when Random Access Response messages are 

transmitted. It unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random 

Access preamble. 

PDCCH-subframe: For FDD UE operation, this represents any subframe; for TDD, only downlink subframes.

NOTE: A timer is running once it is started, until it is stopped or until it expires. 

NOTE: When defining On Duration Timer, DRX Inactivity Timer, DRX Retransmission Timer and Contention 

Resolution Timer, PDCCH-subframes and subframes including DwPTS are considered as subframes 

where the timer, if running, shall be updated. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 

abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 

TR 21.905 [1]. 

BSR Buffer Status Report 

C-RNTI Cell RNTI 

CQI Channel Quality Indicator 

E-UTRA Evolved UMTS Terrestrial Radio Access 

E-UTRAN Evolved UMTS Terrestrial Radio Access Network 

MAC Medium Access Control 

PHR Power Headroom Report 

P-RNTI Paging RNTI 

RA-RNTI Random Access RNTI 

RNTI Radio Network Temporary Identifier 

SI-RNTI System Information RNTI 

SR Scheduling Request 

SRS Sounding Reference Symbols 

TB Transport Block 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 8 of 34
3GPP 

Release 8 8 3GPP TS 36.321 V8.2.0 (2008-05) 

4 General 

4.1 Introduction 

The objective is to describe the MAC architecture and the MAC entity from a functional point of view. 

4.2 MAC architecture 

The description in this sub clause is a model and does not specify or restrict implementations. 

RRC is in control of configuration of MAC. 

4.2.1 MAC Entities 

E-UTRA defines two MAC entities; one in the UE and one in the E-UTRAN. These MAC entities handle the following 

transport channels: 

- Broadcast Channel (BCH); 

- Downlink Shared Channel (DL-SCH); 

- Paging Channel (PCH); 

- Uplink Shared Channel (UL-SCH); 

- Random Access Channel(s) (RACH). 

The exact functions performed by the MAC entities are different in the UE from those performed in the E-UTRAN. 

4.3 Services 

4.3.1 Services provided to upper layers 

This clause describes the different services provided by MAC sublayer to upper layers. 

- data transfer 

- radio resource allocation 

4.3.2 Services expected from physical layer 

The physical layer provides the following services to MAC: 

- data transfer services; 

- signalling of HARQ feedback; 

- signalling of Scheduling Request; 

- measurements (e.g. Channel Quality Indication (CQI)). 

The access to the data transfer services is through the use of transport channels. The characteristics of a transport 

channel are defined by its transport format (or format set), specifying the physical layer processing to be applied to the 

transport channel in question, such as channel coding and interleaving, and any service-specific rate matching as 

needed. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 9 of 34
3GPP 

Release 8 9 3GPP TS 36.321 V8.2.0 (2008-05) 

4.4 Functions 

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. 

The location of the different functions and their relevance for uplink and downlink respectively is illustrated in Table 

4.4-1. 

Table 4.4-1: MAC function location and link direction association. 

MAC function UE eNB Downlink Uplink 

Mapping between logical channels and transport channels X X X 

 X X X 

Multiplexing X X 

 X X 

Demultiplexing X X 

 X X 

Error correction through HARQ X X X 

 X X X 

Transport Format Selection X X X 

Priority handling between UEs X X X 

Priority handling between logical channels of one UE X X X 

Logical Channel prioritisation X X 

Scheduling information reporting X X 

4.5 Channel structure 

The MAC sublayer operates on the channels defined below; transport channels are SAPs between MAC and Layer 1, 

logical channels are SAPs between MAC and RLC. 

4.5.1 Transport Channels 

The transport channels used by MAC are described in Table 4.5.1-1 below. 

Table 4.5.1-1: Transport channels used by MAC 

Transport channel name Acronym Downlink Uplink 

Broadcast Channel BCH X 

Downlink Shared Channel DL-SCH X 

Paging Channel PCH X 

Uplink Shared Channel UL-SCH X 

Random Access Channel RACH X 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 10 of 34
3GPP 

Release 8 10 3GPP TS 36.321 V8.2.0 (2008-05) 

4.5.2 Logical Channels 

The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for 

different kinds of data transfer services as offered by MAC. 

Each logical channel type is defined by what type of information is transferred. 

MAC provides the control and traffic channels listed in Table 4.5.2-1 below. When MAC uses the PDCCH to indicate 

radio resource allocation, the RNTI that is mapped on the PDCCH depends on the logical channel type: 

- C-RNTI, Temporary C-RNTI and Semi-Persistent Scheduling C-RNTI for DCCH and DTCH; 

- P-RNTI for PCCH; 

- RA-RNTI for Random Access Response on DL-SCH; 

- Temporary C-RNTI for CCCH during the random access procedure; 

- SI-RNTI for BCCH. 

Table 4.5.2-1: Logical channels provided by MAC. 

Logical channel name Acronym Control channel Traffic channel 

Broadcast Control Channel BCCH X 

Paging Control Channel PCCH X 

Common Control Channel CCCH X 

Dedicated Control Channel DCCH X 

Dedicated Traffic Channel DTCH X 

4.5.3 Mapping of Transport Channels to Logical Channels 

The mapping of logical channels on transport channels depends on the multiplexing that is configured by RRC. 

4.5.3.1 Uplink mapping 

The MAC entity is responsible for mapping logical channels for the uplink onto uplink transport channels. The uplink 

logical channels can be mapped as described in Figure 4.5.3.1-1 and Table 4.5.3.1-1. 

CCCH DCCH DTCH

RACH UL-SCH

Uplink

Logical channels

Uplink

Transport channels

Figure 4.5.3.1-1 

Table 4.5.3.1-1: Uplink channel mapping. 

 Transport channel 

Logical channel 

UL-SCH RACH 

CCCH X 

DCCH X 

DTCH X 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 11 of 34
3GPP 

Release 8 11 3GPP TS 36.321 V8.2.0 (2008-05) 

4.5.3.2 Downlink mapping 

The MAC entity is responsible for mapping the downlink logical channels to downlink transport channels. The 

downlink logical channels can be mapped as described in Figure 4.5.3.2-1 and Table 4.5.3.2-1. 

PCCH CCCH DCCH BCCH DTCH

PCH DL-SCH BCH

Downlink

Logical channels

Downlink

Transport channels

Figure 4.5.3.2-1 

Table 4.5.3.2-1: Downlink channel mapping. 

 Transport channel 

Logical channel 

BCH PCH DL-SCH 

BCCH X X 

PCCH X 

CCCH X 

DCCH X 

DTCH X 

5 MAC procedures 

5.1 Random Access procedure 

5.1.1 Random Access Procedure initialization 

The Random Access procedure described in this subclause is initiated by a PDCCH order or by the MAC sublayer 

itself. The PDCCH order or RRC optionally indicate a Random Access Preamble and PRACH resource. 

Before the procedure can be initiated, the following information is assumed to be available: 

- the available set of PRACH resources for the transmission of the Random Access Preamble and their 

corresponding RA-RNTIs. 

- the groups of Random Access Preambles and the set of available Random Access Preambles in each group. 

- the thresholds required for selecting one of the two groups of Random Access Preambles. 

- the parameters required to derive the TTI window described in subclause 5.1.4. 

- the power-ramping factor POWER_RAMP_STEP. 

- the parameter PREAMBLE_TRANS_MAX [integer > 0]. 

- the initial preamble power PREAMBLE_ INITIAL_RECEIVED_TARGET_POWER. 

- the parameter Maximum number of Message3 HARQ transmissions. 

[Note that the above parameters may be updated from higher layers before each Random Access procedure is initiated.] 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 12 of 34
3GPP 

Release 8 12 3GPP TS 36.321 V8.2.0 (2008-05) 

The Random Access procedure shall be performed as follows: 

- Flush the [Message3] buffer; 

- set the PREAMBLE_TRANSMISSION_COUNTER to 1; 

- set the backoff parameter value in the UE to 0 ms; 

- proceed to the selection of the Random Access Resource (see subclause 5.1.2). 

NOTE: There is only one Random Access procedure ongoing at any point in time. If the UE receives a request for 

a new Random Access procedure while another is already ongoing, it is up to UE implementation whether 

to continue with the ongoing procedure or start with the new procedure. 

5.1.2 Random Access Resource selection 

The Random Access Resource procedure shall be performed as follows: 

- If the Random Access Preamble and PRACH resource have been explicitly signalled and the Random Access 

Preamble expiration time, if configured, has not expired: 

- the UE can directly proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

- else the Random Access Preamble shall be selected by the UE as follows: 

- If the uplink message containing the C-RNTI MAC control element or the uplink message including the 

CCCH SDU has not yet been transmitted, the UE shall: 

- depending on the size of the message to be transmitted on the UL or the requested resource blocks [FFS] 

[the selection also depends on radio conditions], select one of the two groups of Random Access 

Preambles configured by RRC. 

- else, if the uplink message containing the C-RNTI MAC control element or the uplink message including the 

CCCH SDU is being retransmitted, the UE shall: 

- select the same group of Random Access Preambles as was used for the preamble transmission attempt 

corresponding to the first transmission of the uplink message containing the C-RNTI MAC control 

element or the uplink message including the CCCH SDU. 

- randomly select a Random Access Preamble within the selected group. The random function shall be such 

that each of the allowed selections can be chosen with equal probability; 

- if more than one PRACH resources are available in the same subframe (TDD), randomly select one. The 

random function shall be such that each of the allowed selections can be chosen with equal probability; 

- proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

5.1.3 Random Access Preamble transmission 

The random-access procedure shall be performed as follows: 

- If PREAMBLE_TRANSMISSION_COUNTER = PREAMBLE_TRANS_MAX + 1: 

- indicate a Random Access problem to upper layers. 

[- set the parameter PREAMBLE_RECEIVED_TARGET_POWER to 

PREAMBLE_INITIAL_RECEIVED_TARGET_POWER + (PREAMBLE_TRANSMISSION_COUNTER-1) * 

POWER_RAMP_STEP;] 

- determine the next available Random Access occasion; 

- instruct the physical layer to transmit a preamble using the selected PRACH resource, corresponding RA-RNTI, 

preamble index and PREAMBLE_RECEIVED_TARGET_POWER. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 13 of 34
3GPP 

Release 8 13 3GPP TS 36.321 V8.2.0 (2008-05) 

5.1.4 Random Access Response reception 

Once the Random Access Preamble is transmitted, the UE shall monitor the PDCCH associated with the RA-RNTI 

defined below in the TTI window [RA_WINDOW_BEGIN—RA_WINDOW_END] for Random Access Response(s) 

identified by the RA-RNTI. The RA-RNTI associated with the PRACH resource in which the Random Access 

Preamble is transmitted, is computed as: 

RA-RNTI= t_id+10*f_id 

Where t_id is the index of the first subframe of the specified PRACH resource (0≤ t_id <10), and f_id is the index of the 

specified PRACH resource within that subframe, in ascending order of frequency domain (0≤ f_id< 6). The UE may 

stop monitoring for Random Access Response(s) after successful reception of a Random Access Response 

corresponding to the Random Access Preamble transmission. 

- If notification of a reception of the Random Access Response is received from lower layers, the UE shall: 

- if the Random Access Response contains a Backoff Indicator subheader: 

- set the backoff parameter value in the UE as indicated by the BI field of the Backoff Indicator subheader 

and Table 7.2-1. 

- else, set the backoff parameter value in the UE to 0 ms. 

- if the Random Access Response contains a Random Access Preamble identifier corresponding to the 

transmitted Random Access Preamble (see subclause 5.1.3), the UE shall: 

- consider this Random Access Response reception successful; 

- process the received Timing Alignment value (see subclause 5.2); 

- process the received UL grant value; 

- if the Random Access Preamble was explicitly signalled (i.e., not selected by MAC): 

- consider the Random Access procedure successfully completed. 

- else, if the Random Access Preamble was selected by UE MAC: 

- set the Temporary C-RNTI to the value received in the Random Access Response message no later 

than at the time of the first transmission corresponding to the UL grant provided in the Random 

Access Response message; 

- if this is the first successfully received Random Access Response within this Random Access 

procedure: 

- if the UE is in RRC_CONNECTED state [except for RLF], indicate to the Multiplexing and 

assembly entity to include a C-RNTI MAC control element in the subsequent uplink transmission; 

- obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity and store it in the 

[Message3] buffer. 

NOTE: When an uplink transmission is required, e.g., for contention resolution, the eNB should not provide a 

grant smaller than 80 bits in the Random Access Response. 

NOTE: If within a Random Access procedure, an uplink grant provided in the Random Access Response for the 

same group of Random Access Preambles has a different size than the first uplink grant allocated during 

that Random Access procedure, the UE behavior is not defined. 

If no Random Access Response is received within the TTI window [RA_WINDOW_BEGIN—RA_WINDOW_END], 

or if all received Random Access Responses contain Random Access Preamble identifiers that do not match the 

transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE 

shall: 

- if the Random Access procedure was initiated by the MAC sublayer itself; or 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 14 of 34
3GPP 

Release 8 14 3GPP TS 36.321 V8.2.0 (2008-05) 

- if the Random Access procedure was initiated by a PDCCH order and the 

PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1; 

- if in this Random Access procedure: 

- the Random Access Preamble was selected by MAC; or 

- the Random Access Preamble and PRACH resource were explicitly signalled and will expire before the 

next available Random Access occasion: 

- based on the backoff parameter in the UE, compute and apply a backoff value indicating when a new 

Random Access transmission shall be attempted; 

 - proceed to the selection of a Random Access Resource (see subclause 5.1.2). 

Editor’s note: Whether error conditions are specified is FFS. 

5.1.5 Contention Resolution 

Contention Resolution is based on C-RNTI on PDCCH and UE Contention Resolution Identity on DL-SCH.. 

Once the uplink message containing the C-RNTI MAC control element or the uplink message including the CCCH 

SDU is transmitted, the UE shall: 

- start the Contention Resolution Timer; 

- monitor the PDCCH until the Contention Resolution Timer expires; 

- if notification of a reception of a PDCCH transmission is received from lower layers, the UE shall: 

- if the C-RNTI MAC control element was included in uplink message: 

- if the Random Access procedure was initiated by the MAC sublayer itself and the PDCCH transmission is 

addressed to the C-RNTI and contains an UL grant; or 

- if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is 

addressed to the C-RNTI: 

- consider this Contention Resolution successful; 

- stop the Contention Resolution Timer; 

- discard the Temporary C-RNTI; 

- consider this Random Access procedure successfully completed. 

- else if the uplink message includes the CCCH SDU and the PDCCH transmission is addressed to its 

Temporary C-RNTI: 

- if the MAC PDU is successfully decoded: 

- stop the Contention Resolution Timer; 

- if the MAC PDU contains a UE Contention Resolution Identity MAC control element; and 

- if the UE Contention Resolution Identity included in the MAC control element matches the CCCH 

SDU transmitted in the uplink message: 

- consider this Contention Resolution successful and finish the disassembly and demultiplexing of 

the MAC PDU; 

- set the C-RNTI to the value of the Temporary C-RNTI; 

- consider this Random Access procedure successfully completed. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 15 of 34
3GPP 

Release 8 15 3GPP TS 36.321 V8.2.0 (2008-05) 

- else 

- consider this Contention Resolution not successful and discard the successfully decoded MAC 

PDU. 

- discard the Temporary C-RNTI. 

- if the Contention Resolution Timer expires: 

- consider the Contention Resolution not successful. 

- if the Contention Resolution is considered not successful the UE shall: 

- if the Random Access procedure was initiated by the MAC sublayer itself; or 

- if the Random Access procedure was initiated by a PDCCH order and the 

PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1; 

- based on the backoff parameter in the UE, compute and apply a backoff value indicating when a new 

Random Access transmission shall be attempted; 

- proceed to the selection of a Random Access Resource (see subclause 5.1.2). 

- discard the Temporary C-RNTI. 

5.1.6 Completion of the Random Access procedure 

At successful completion of the Random Access procedure, the UE shall: 

- if the PREAMBLE_TRANSMISSION_COUNTER is greater than PREAMBLE_TRANS_MAX: 

- indicate recovery from a Random Access problem to upper layers. 

5.2 Maintenance of Uplink Time Alignment 

The UE has a configurable Time Alignment Timer. The Time Alignment Timer is valid only in the cell for which it was 

configured and started. 

If the Time Alignment Timer has been configured, the UE shall: 

- when a Timing Advance MAC control element is received: 

- apply the Timing Advance Command; 

- start the Time Alignment Timer (if not running) or restart the Time Alignment Timer (if already running). 

- when a Time Alignment Command is received in a Random Access Response message: 

- if the Random Access Preamble and PRACH resource were explicitly signalled: 

- apply the Time Alignment Command; 

- start the Time Alignment Timer (if not running) or restart the Time Alignment Timer (if already running). 

- else, if the Time Alignment Timer is not running or has expired: 

- apply the Time Alignment Command; 

- start the Time Alignment Timer; 

- when the contention resolution is considered not successful as described in subclause 5.1.5, stop the Time 

Alignment Timer. 

- else: 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 16 of 34
3GPP 

Release 8 16 3GPP TS 36.321 V8.2.0 (2008-05) 

- ignore the received Time Alignment Command. 

- when the Time Alignment Timer has expired or is not running: 

- prior to any uplink transmission, use the Random Access procedure (see subclause 5.1) in order to obtain 

uplink Time Alignment. 

- when the Time Alignment Timer expires: 

- release all PUCCH resources; 

- release any assigned SRS resources. 

5.3 DL-SCH data transfer 

Editor’s note: Current text applies to, at least, FDD. 

5.3.1 DL Assignment reception 

Editor’s note: A downlink assignment can relate to one or two (MIMO) TBs. It is FFS how this information is 

presented to MAC. 

When the UE has a C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI or RA-RNTI, the UE shall for 

each TTI during Active Time, for each TTI when a Random Access Response or Contention Resolution is expected and 

for each TTI for which a DL assignment has been configured: 

- if a downlink assignment for this TTI has been received on the PDCCH for the UE’s C-RNTI, Temporary 

C-RNTI or RA-RNTI: 

- indicate a downlink assignment and the associated HARQ information to the HARQ entity for this TTI. 

- else, if a downlink assignment for this TTI has been configured: 

- indicate a downlink assignment, for a new transmission, and the associated HARQ information to the HARQ 

entity for this TTI. 

When the UE needs to read BCCH, the UE shall: 

- if a downlink assignment for this TTI has been received on the PDCCH for the SI-RNTI; 

- indicate a downlink assignment for the dedicated broadcast HARQ process to the HARQ entity for this TTI. 

NOTE: Downlink assignments for both C-RNTI and SI-RNTI can be received in the same TTI. 

Editor’s note: L1 is configured, as needed, by upper layers or MAC [FFS] to monitor PDCCH for C-RNTI, and by 

MAC to monitor PDCCH for Temporary C-RNTI and RA-RNTI. 

5.3.2 HARQ operation 

5.3.2.1 HARQ Entity 

There is one HARQ entity at the UE which processes the HARQ process identifiers indicated by the HARQ information 

associated with TBs received on the DL-SCH and directs the received data to the corresponding HARQ process for 

reception operations (see subclause 5.3.2.2). 

A number of parallel HARQ processes are used in the UE to support the HARQ entity. [The number of HARQ 

processes is FFS]. 

 If a downlink assignment has been indicated or configured for this TTI, the UE shall: 

- allocate the received TB to the HARQ process indicated by the associated HARQ information. 

If a downlink assignment has been indicated for the broadcast HARQ process, the UE shall: 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 17 of 34
3GPP 

Release 8 17 3GPP TS 36.321 V8.2.0 (2008-05) 

- allocate the received TB to the broadcast HARQ process. 

NOTE: In case of BCCH a dedicated broadcast HARQ process is used. 

5.3.2.2 HARQ process 

For each received TB: 

- if the NDI, when provided, has been incremented compared to the value of the previous received transmission 

for this HARQ process; or 

- if the HARQ process is equal to the broadcast process and the physical layer indicates a new transmission; or 

- if this is the very first received transmission for this HARQ process: 

- a new transmission is indicated for this HARQ process. 

- else, a retransmission is indicated for this HARQ process. 

The UE then shall: 

- if a new transmission is indicated for this HARQ process: 

- replace the data currently in the soft buffer for this HARQ process with the received data. 

- if a retransmission is indicated for this HARQ process: 

- if the data has not yet been successfully decoded: 

- combine the received data with the data currently in the soft buffer for this HARQ process. 

- if the TB size is different from the last valid TB size signalled for this HARQ process: 

- the UE may replace the data currently in the soft buffer for this HARQ process with the received data. 

- attempt to decode the data in the soft buffer; 

- if the data in the soft buffer was successfully decoded: 

- if the HARQ process is equal to the broadcast process, deliver the decoded MAC PDU to RRC. 

- else, deliver the decoded MAC PDU to the disassembly and demultiplexing entity. 

- generate a positive acknowledgement (ACK) of the data in this HARQ process. 

- else: 

- generate a negative acknowledgement (NACK) of the data in this HARQ process. 

- if the HARQ process is associated with a transmission indicated with an RA-RNTI; or 

- if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and a UE Contention 

Resolution Identity match is not indicated; or 

- if the HARQ process is equal to the broadcast process: 

- do not indicate the generated positive or negative acknowledgement to the physical layer. 

- else: 

- indicate the generated positive or negative acknowledgement to the physical layer. 

5.3.3 Disassembly and demultiplexing 

Editor’s note: This section describes the disassembly and demultiplexing of MAC PDUs into MAC SDUs. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 18 of 34
3GPP 

Release 8 18 3GPP TS 36.321 V8.2.0 (2008-05) 

5.4 UL-SCH data transfer 

Editor’s note: Current text applies to, at least, FDD. 

5.4.1 UL Grant reception 

When the UE has a C-RNTI, Semi-Persistent Scheduling C-RNTI, or Temporary C-RNTI, the UE shall for each TTI: 

- if an uplink grant for this TTI has been received on the PDCCH for the UE’s C-RNTI or Temporary C-RNTI; or 

- if an uplink grant for this TTI has been received in a Random Access Response: 

- indicate a valid uplink grant and the associated HARQ information to the HARQ entity for this TTI. 

- else, if an uplink grant for this TTI has been configured: 

- indicate an uplink grant, valid for new transmission, and the associated HARQ information to the HARQ 

entity for this TTI. 

NOTE: The period of configured uplink grants is expressed in TTIs. 

NOTE: If the UE receives both a grant for its RA-RNTI and a grant for its C-RNTI, the UE may choose to 

continue with either the grant for its RA-RNTI or the grant for its C-RNTI. 

5.4.2 HARQ operation 

5.4.2.1 HARQ entity 

There is one HARQ entity at the UE. A number of parallel HARQ processes are used in the UE to support the HARQ 

entity, allowing transmissions to take place continuously while waiting for the feedback on the successful or 

unsuccessful reception of previous transmissions. 

At a given TTI, if an uplink grant is indicated for the TTI, the HARQ entity identifies the HARQ process for which a 

transmission should take place. It also routes the receiver feedback (ACK/NACK information), MCS and resource, 

relayed by the physical layer, to the appropriate HARQ process. 

If TTI bundling is configured, the parameter TTI_BUNDLE_SIZE provides the number of TTIs of a TTI bundle. If a 

transmission is indicated for the TTI, the HARQ entity identifies the HARQ process for which a transmission should 

take place. The next TTI_BUNDLE_SIZE uplink TTIs are subsequently used for transmissions for the identified 

HARQ process. HARQ retransmissions within a bundle shall be performed without waiting for feedback from previous 

transmissions according to TTI_BUNDLE_SIZE. The UE expects feedback only for the last transmission of a bundle. 

For transmission of an uplink message containing the C-RNTI MAC control element or an uplink message including a 

CCCH SDU during Random Access (see section 5.1.5) TTI bundling does not apply. 

The number of HARQ processes is equal to [X] [FFS]. Each process is associated with a number from 0 to [X-1]. 

At the given TTI, the HARQ entity shall: 

- if an uplink grant indicating that the NDI has been incremented compared to the value in the previous 

transmission of this HARQ process is indicated for this TTI or if this is the very first transmission for this HARQ 

process (i.e. a new transmission takes place for this HARQ process): 

- if there is an ongoing Random Access procedure and there is a MAC PDU in the [Message3] buffer: 

- obtain the MAC PDU to transmit from the [Message3] buffer. 

- else, if the "uplink prioritisation" entity indicates the need for a new transmission: 

- obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity; 

- instruct the HARQ process corresponding to this TTI to trigger a new transmission using the identified 

parameters. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 19 of 34
3GPP 

Release 8 19 3GPP TS 36.321 V8.2.0 (2008-05) 

- else: 

- flush the HARQ buffer. 

- else, if an uplink grant, indicating that the NDI is identical to the value in the previous transmission of this 

HARQ process (i.e. a retransmission takes place for this HARQ process), is indicated for this TTI: 

- instruct the HARQ process to generate an adaptive retransmission. 

- else, if the HARQ buffer of the HARQ process corresponding to this TTI is not empty: 

- instruct the HARQ process to generate a non-adaptive retransmission. 

NOTE: A retransmission triggered by the HARQ entity should be cancelled by the corresponding HARQ process 

if it collides with a measurement gap or if a non-adaptive retransmission is not allowed. 

5.4.2.2 HARQ process 

Each HARQ process is associated with a HARQ buffer. 

Each HARQ process shall maintain a state variable CURRENT_TX_NB, which indicates the number of transmissions 

that have taken place for the MAC PDU currently in the buffer. When the HARQ process is established, 

CURRENT_TX_NB shall be initialized to 0. 

The sequence of redundancy versions is defined to be 0, 2, 3, 1. The variable CURRENT_IRV provides a pointer to a 

redundancy version in the defined set. This variable is up-dated modulo 4. 

New transmissions and adaptive retransmisions are performed on the resource and with the MCS indicated on PDCCH, 

while a non-adaptive retransmission is performed on the same resource and with the same MCS as was used for the last 

made transmission attempt, 

The UE is configured with a Maximum number of HARQ transmissions and a Maximum number of Message3 HARQ 

transmissions by RRC. For transmissions on all HARQ processes and all logical channels except for transmission of a 

MAC PDU stored in the [Message3] buffer, maximum number of transmissions shall be set to Maximum number of 

HARQ transmissions. For transmission of a MAC PDU stored in the [Message3] buffer, maximum number of 

transmissions shall be set to Maximum number of Message3 HARQ transmissions. 

If the HARQ entity requests a new transmission, the HARQ process shall: 

- set CURRENT_TX_NB to 0; 

- set CURRENT_IRV to 0; 

- store the MAC PDU in the associated HARQ buffer; 

- generate a transmission as described below. 

If the HARQ entity requests a retransmission, the HARQ process shall: 

- increment CURRENT_TX_NB by 1; 

- if there is no measurement gap at the time of the retransmission: 

- for an adaptive retransmission: 

- set CURRENT_IRV to the value corresponding to the redundancy version indicated on PDCCH; 

- generate a transmission as described below. 

- for a non-adaptive retransmission: 

- if the last feedback for this HARQ process is a HARQ NACK: 

- generate a transmission as described below. 

NOTE: When receiving a HARQ ACK alone, the UE keeps the data in the HARQ buffer. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 20 of 34
3GPP 

Release 8 20 3GPP TS 36.321 V8.2.0 (2008-05) 

To generate a transmission, the HARQ process shall: 

- instruct the physical layer to generate a transmission with the redundancy version corresponding to the 

CURRENT_IRV value and the transmission timing; 

- increment CURRENT_IRV by 1; 

- if there is a measurement gap at the time of the feedback for this transmission, consider the feedback coinciding 

with the measurement gap to be a HARQ ACK. 

The HARQ process shall: 

- if CURRENT_TX_NB = maximum number of transmissions: 

- flush the HARQ buffer; 

- if the transmission corresponds to a transmission of CCCH; and 

- if the last feedback received (i.e., the feedback received for the last transmission of this process) is a 

HARQ NACK: 

- notify RRC that the transmission of the corresponding MAC SDU failed. 

The HARQ process may: 

- if CURRENT_TX_NB = maximum number of transmissions configured; and 

- if the last feedback received (i.e., the feedback received for the last transmission of this process) is a HARQ 

NACK: 

- notify the relevant ARQ entities in the upper layer that the transmission of the corresponding RLC PDUs 

failed. 

5.4.3 Multiplexing and assembly 

Editor’s note: This subclause describes the procedure for creation of MAC SDUs including multiplexing of MAC 

SDUs and creating the MAC header. 

5.4.3.1 Logical channel prioritization 

The Logical Channel Prioritization procedure is applied when a new transmission is performed. 

RRC can control the scheduling of uplink data by giving each logical channel a priority where increasing priority values 

indicate lower priority levels. In addition, each logical channel is given a Prioritized Bit Rate (PBR). 

The UE shall perform the following Logical Channel Prioritization procedure when a new transmission is performed: 

- The UE shall allocate resources to the logical channels in the following sequence: 

- all the logical channels are allocated resources in a decreasing priority order up to a value such that on 

average, the served data rate for radio bearers that have data for transmission equals the configured PBR for 

the radio bearer. If the PBR of a radio bearer is set to “infinity”, the UE shall allocate resources for all the 

data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio 

bearer(s); 

- if any resources remain, all the logical channels are served in a strict decreasing priority order until either the 

data for that logical channel or the UL grant is exhausted, whichever comes first. 

- The UE shall also follow the rules below during the scheduling procedures above: 

- the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the 

whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources; 

- if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill 

the grant as much as possible; 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 21 of 34
3GPP 

Release 8 21 3GPP TS 36.321 V8.2.0 (2008-05) 

- the UE shall serve as much data as it can to fill the grant in general. However, if the remaining resources 

require the UE to segment an RLC SDU with size smaller than x bytes or smaller than the L2 header size 

(FFS), the UE may use padding to fill the remaining resources instead of segmenting the RLC SDU and 

sending the segment. 

Logical channels configured with the same priority shall be served equally the by UE. 

MAC control elements for BSR, with exception of Padding BSR, have higher priority than U-plane Logical Channels. 

At serving cell change, the first UL-DCCH MAC SDU to be transmitted in the new cell has higher priority than MAC 

control elements for BSR. 

5.4.3.2 Multiplexing of MAC SDUs 

Editor’s note: This subclause describes the construction of MAC PDUs from MAC SDUs as prioritised and selected 

by the Logical channel prioritisation entity. 

5.4.4 Scheduling Request 

The Scheduling Request (SR) is for requesting UL-SCH resources. 

If an SR has been triggered, the UE shall for each TTI, until UL-SCH resources are granted for a new transmission: 

- if no UL-SCH resources are available in this TTI: 

- if a PUCCH is configured for the UE to send an SR in this TTI, instruct the physical layer to signal the SR on 

PUCCH; 

- if no PUCCH for SR is configured for the UE in any TTI, initiate a Random Access procedure (see subclause 

5.1). 

NOTE: A triggered SR is considered pending and is repeated until UL-SCH resources are granted for a new 

transmission. 

5.4.5 Buffer Status Reporting 

The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data in 

the UL buffers of the UE. 

A Buffer Status Report (BSR) shall be triggered if any of the following events occur: 

- UL data arrives in the UE transmission buffer and the data belongs to a logical channel with higher priority than 

those for which data already existed in the UE transmission buffer, in which case the BSR is referred below to as 

“Regular BSR”; 

- UL resources are allocated and number of padding bits is larger than the size of the Buffer Status Report MAC 

control element, in which case the BSR is referred below to as “Padding BSR”; 

- a serving cell change occurs, in which case the BSR is referred below to as “Regular BSR”; 

- the PERIODIC BSR TIMER expires, in which case the BSR is referred below to as “Periodic BSR”. 

For Regular and Periodic BSR: 

- if only one LCG has buffered data in the TTI where the BSR is transmitted: report short BSR; 

- else if more than one LCG has buffered data in the TTI where the BSR is transmitted: report long BSR. 

For padding BSR: 

- if the number of padding bits is equal to or larger than the size of the Short BSR but smaller than the size of the 

Long BSR, report Short BSR of the LCG with the highest priority logical channel with buffered data; 

- else if the number of padding bits is equal to or larger than the size of the Long BSR, report Long BSR. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 22 of 34
3GPP 

Release 8 22 3GPP TS 36.321 V8.2.0 (2008-05) 

If the Buffer Status reporting procedure determines that a BSR has been triggered since the last transmission of a BSR: 

- if the UE has UL resources allocated for new transmission for this TTI: 

- instruct the Multiplexing and Assembly procedure to generate a BSR MAC control element; 

- restart the PERIODIC BSR TIMER. 

- else if a Regular BSR has been triggered since the last transmission of a BSR: 

- a Scheduling Request shall be triggered. 

NOTE: Even if multiple events occur by the time a BSR can be transmitted, only one BSR will be included in the 

MAC PDU. 

A pending BSR shall be cancelled in case the UL grant can accommodate all pending data but is not sufficient to 

accommodate the BSR MAC control element in addition. 

5.4.6 Power Headroom Reporting 

The Power Headroom reporting procedure is used to provide the serving eNB with information about the difference 

between the UE TX power and the maximum UE TX power (for the positive values of the power headroom) and about 

the difference between the maximum UE TX power and the calculated UE TX power, according to the UL power 

control formula, when it exceeds the maximum UE TX power (for the negative values of the power headroom). 

A Power Headroom Report (PHR) shall be triggered if any of the following events occur: 

- the PROHIBIT_PHR_TIMER expires or has expired and the path loss has changed more than 

DL_PathlossChange dB since the last power headroom report; 

- the PERIODIC PHR TIMER expires, in which case the PHR is referred below to as “Periodic PHR”. 

If the Power Headroom reporting procedure determines that a PHR has been triggered since the last transmission of a 

PHR: 

- if the UE has UL resources allocated for new transmission for this TTI: 

- obtain the value of the power headroom from the physical layer; 

- instruct the Multiplexing and Assembly procedure to generate a PHR MAC control element based on the 

value reported by the physical layer; 

- if the PHR is a “Periodic PHR”, restart the PERIODIC PHR TIMER; 

- restart the PROHIBIT_PHR_TIMER. 

NOTE: Even if multiple events occur by the time a PHR can be transmitted, only one PHR is included in the 

MAC PDU. 

Editor’s note: When periodic Power Headroom Reporting is configured, the first report should be included 

immediately when the UE has a grant for a new transmission. 

5.5 PCH reception 

When in RRC_IDLE, the UE shall at its paging occasions: 

- if a PCH assignment has been received on the PDCCH for the P-RNTI: 

- attempt to decode the TB on the PCH as indicated by the PDCCH information. 

- if a TB on the PCH has been successfully decoded: 

- deliver the decoded MAC PDU to higher layers. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 23 of 34
3GPP 

Release 8 23 3GPP TS 36.321 V8.2.0 (2008-05) 

5.6 BCH reception 

 When the UE needs to receive BCH, the UE shall: 

- receive and attempt to decode the BCH; 

- if a TB on the BCH has been successfully decoded: 

- deliver the decoded MAC PDU to higher layers. 

5.7 Discontinuous Reception (DRX) 

The UE may be configured by RRC with a DRX functionality that allows it to not continuously monitor the PDCCH. 

The DRX functionality consists of a Long DRX cycle, a DRX Inactivity Timer, a DRX Retransmission Timer and 

optionally a Short DRX Cycle and a DRX Short Cycle Timer, all defined in subclause 3.1. 

When a DRX cycle is configured, the Active Time includes the time while: 

- the On Duration Timer or the DRX Inactivity Timer or a DRX Retransmission Timer or the Contention 

Resolution Timer is running; or 

- a Scheduling Request is pending (as described in subclause 5.4.4); or 

- an uplink grant for a retransmission can occur; or 

- a PDCCH indicating a new transmission addressed to the C-RNTI or Temporary C-RNTI of the UE has not been 

received after successful reception of a Random Access Response (as described in subclause 5.1.4). 

When a DRX cycle is configured, the UE shall for each subframe: 

- start the On Duration Timer when [(SFN * 10) + subframe number] modulo (current DRX Cycle) = DRX Start 

Offset; 

- if a HARQ RTT Timer expires in this subframe and the data in the soft buffer of the corresponding HARQ 

process was not successfully decoded: 

- start the DRX Retransmission Timer for the corresponding HARQ process. 

- if a DRX Command MAC control element is received: 

- stop the On Duration Timer; 

- stop the DRX Inactivity Timer. 

- if the DRX Inactivity Timer expires or a DRX Command MAC control element is received in this subframe: 

- if the short DRX cycle is configured: 

 - start the DRX Short Cycle Timer and use the Short DRX Cycle. 

- else: 

- use the Long DRX cycle. 

- if the DRX Short Cycle Timer expires in this subframe: 

- use the long DRX cycle. 

- during the Active Time, for a PDCCH-subframe except if the subframe is required for uplink transmission for 

half-duplex FDD UE operation: 

- monitor the PDCCH; 

- if the PDCCH indicates a DL transmission: 

- start the HARQ RTT Timer for the corresponding HARQ process; 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 24 of 34
3GPP 

Release 8 24 3GPP TS 36.321 V8.2.0 (2008-05) 

- stop the DRX Retransmission Timer for the corresponding HARQ process. 

- if the PDCCH indicates a new transmission (DL or UL): 

- start or restart the DRX Inactivity Timer. 

- if a DL assignment has been configured for this subframe and no PDCCH indicating a DL transmission was 

successfully decoded: 

- start the HARQ RTT Timer for the corresponding HARQ process. 

- when not in active time, CQI and SRS shall not be reported. 

Regardless of whether the UE is monitoring PDCCH or not the UE receives and transmits HARQ feedback when such 

is expected. 

5.8 MAC reconfiguration 

Editor’s note: This subclause describes the procedure for handling reconfiguration of MAC parameters during 

normal operation. 

5.9 MAC Reset 

Editor’s note: This subclause describes the procedure for resetting MAC [FFS]; e.g. at handover. 

5.X Handling of unknown, unforeseen and erroneous protocol 

data 

Editor’s note: This subclause describes how MAC treats and acts on unexpected data. 

Editor’s note: The subclause on “Handling of unknown, unforeseen and erroneous protocol data” should be the last 

subsection of Section “MAC procedures”. 

6 Protocol Data Units, formats and parameters 

6.1 Protocol Data Units 

6.1.1 General 

A MAC PDU is a bit string that is byte aligned (i.e. multiple of 8 bits) in length. In the figures in subclause 6.1, bit 

strings are represented by tables in which the most significant bit is the leftmost bit of the first line of the table, the least 

significant bit is the rightmost bit on the last line of the table, and more generally the bit string is to be read from left to 

right and then in the reading order of the lines. The bit order of each parameter field within a MAC PDU is represented 

with the first and most significant bit in the leftmost bit and the last and least significant bit in the rightmost bit. 

MAC SDUs are bit strings that are byte aligned (i.e. multiple of 8 bits) in length. An SDU is included into a MAC PDU 

from the first bit onward. 

6.1.2 MAC PDU (DL-SCH and UL-SCH) 

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC 

control elements, and optionally padding; as described in Figure 6.1.2-3. 

Both the MAC header and the MAC SDUs are of variable sizes. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 25 of 34
3GPP 

Release 8 25 3GPP TS 36.321 V8.2.0 (2008-05) 

A MAC PDU header consists of one or more MAC PDU sub-headers; each subheader corresponding to either a MAC 

SDU, a MAC control element or padding. 

A MAC PDU subheader consists of the six header fields R/R/E/LCID/F/L but for the last subheader in the MAC PDU 

and for fixed sized MAC control elements. The last subheader in the MAC PDU and sub-headers for fixed sized MAC 

control elements consist solely of the four header fields R/R/E/LCID. It follows that a MAC PDU subheader 

corresponding to padding consists of the four header fields R/R/E/LCID. 

Figure 6.1.2-1: R/R/E/LCID/F/L MAC subheader 

Figure 6.1.2-2: R/R/E/LCID MAC subheader 

MAC PDU sub-headers have the same order as the corresponding MAC SDUs, MAC control elements and padding. 

MAC control elements, except Padding BSR, are always placed before any MAC SDU. Padding BSR occurs at the end 

of the MAC PDU. 

Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required but cannot be 

achieved by padding at the end of 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, one 

or two MAC PDU sub-headers corresponding to padding are inserted before the first MAC PDU subheader 

corresponding to a MAC SDU; or if such subheader is not present, before the last MAC PDU subheader corresponding 

to a MAC control element. 

A maximum of one MAC PDU can be transmitted per TB per UE. [Depending on the physical layer category], one or 

two TBs can be transmitted per TTI per UE. 

MAC Control 

element 1 ...

R/R/E/LCID 

sub-header

MAC header

MAC payload

R/R/E/LCID[/F/L] 

sub-header

R/R/E/LCID/F/L 

sub-header

R/R/E/LCID/F/L 

sub-header ... R/R/E/LCID/F/L sub-header

R/R/E/LCID padding 

sub-header

MAC Control 

element 2 MAC SDU MAC SDU Padding (opt)

Figure 6.1.2-3: MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 26 of 34
3GPP 

Release 8 26 3GPP TS 36.321 V8.2.0 (2008-05) 

Editor’s note: It is FFS whether this MAC PDU applies only to DL/UL SCH or also to other transport channels 

6.1.3 MAC Control Elements 

6.1.3.1 Buffer Status Report MAC Control Elements 

Buffer Status Report (BSR) MAC control elements consist of either: 

- Short BSR format: one LCG ID field and one corresponding BS field (figure 6.1.3.1-1); or 

- Long BSR format: four Buffer Size fields, corresponding to LCG IDs #1 through #4 (figure 6.1.3.1-2). 

The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in table 6.2.1.-1. 

The fields LCG ID and BS are defined as follow: 

- LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is 

being reported. The length of the field is 2 bits; 

- Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a 

logical channel group after the MAC PDU has been built. The amount of data is indicated in number of bytes. It 

shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of 

what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of 

the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. 

The values taken by the Buffer Size field are shown in [Table 6.1.2.1-1]. 

Figure 6.1.3.1-1: Short Buffer Status MAC control element 

Figure 6.1.3.1-2: Long Buffer Status MAC control element 

6.1.3.2 C-RNTI MAC Control Element 

The C-RNTI MAC control element is identified by MAC PDU subheader with LCID as specified in table 6.2.1-2. 

It has a fixed size and consists of a single field defined as follows (figure 6.1.3.2-1): 

- C-RNTI: This field contains the C-RNTI of the UE. The length of the field is 16 bits. 

Figure 6.1.3.2-1: C-RNTI MAC control element 

6.1.3.3 DRX Command MAC Control Element 

The DRX Command MAC control element is identified by a MAC PDU subheader with LCID as specified in table 

6.2.1-1. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 27 of 34
3GPP 

Release 8 27 3GPP TS 36.321 V8.2.0 (2008-05) 

It has a fixed size of zero bits. 

6.1.3.4 UE Contention Resolution Identity MAC Control Element 

The UE Contention Resolution Identity MAC control element is identified by MAC PDU subheader with LCID as 

specified in table 6.2.1-1. This control element has a fixed 48-bit size and consists of a single field defined as follows 

(figure 6.1.3.4-1) 

- UE Contention Resolution Identity: This field contains the uplink CCCH SDU transmitted by MAC. 

Figure 6.1.3.4-1: UE Contention Resolution Identity MAC control element 

6.1.3.5 Timing Advance MAC Control Element 

The Timing Advance MAC control element is identified by MAC PDU subheader with LCID as specified in table 

6.2.1-1. 

It has a fixed size and consists of a single field defined as follows (figure 6.1.3.4-1): 

- Timing Advance: This field indicates the amount of timing adjustment in 0.5 s that UE has to apply. The length 

of the field is [8] bits. 

Figure 6.1.3.5-1: Timing Advance MAC control element 

Editor’s note: Whether all 8 bits are needed and what the value range is are FFS. 

6.1.3.6 Power Headroom MAC Control Element 

The Power Headroom MAC control element is identified by a MAC PDU subheader with LCID as specified in table 

6.2.1-1. It has a fixed size and consists of a single octet defined as follows (figure 6.1.3.6-1): 

- R: reserved bits; 

- Power Headroom: this field indicates the power headroom. The length of the field is 6 bits. 

Figure 6.1.3.5-1: Power Headroom MAC control element 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 28 of 34
3GPP 

Release 8 28 3GPP TS 36.321 V8.2.0 (2008-05) 

6.1.4 MAC PDU (transparent MAC) 

A MAC PDU consists solely of a MAC Service Data Unit (MAC SDU) whose size is aligned to a TB; as described in 

figure 6.1.4-1. 

MAC SDU 

MAC payload

Figure 6.1.4-1: MAC PDU (transparent MAC) 

6.1.5 MAC PDU (Random Access Response) 

A MAC PDU consists of a MAC header and one or more MAC Random Access Responses (MAC RAR) as described 

in figure 6.1.5-4. 

The MAC header is of variable size. 

A MAC PDU header consists of one or more MAC PDU sub-headers; each subheader corresponding to a MAC RAR 

except for the Backoff Indicator sub-header. 

A MAC PDU subheader consists of the three header fields E/T/RAPID (as described in figure 6.1.5-1) but for the 

Backoff Indicator subheader which consists of the five header field E/T/R/R/BI (as described in figure 6.1.5-2). 

A MAC RAR consists of the three fields TA/UL Grant/Temporary C-RNTI (as described in figure 6.1.5-3) 

Figure 6.1.5-1: E/T/RAPID MAC sub-header 

Figure 6.1.5-2: E/T/R/R/BI MAC sub-header 

Figure 6.1.5-3: MAC RAR 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 29 of 34
3GPP 

Release 8 29 3GPP TS 36.321 V8.2.0 (2008-05) 

Figure 6.1.5-4: MAC PDU consisting of a MAC header and MAC RARs 

6.2 Formats and parameters 

6.2.1 MAC header for DL-SCH and UL-SCH 

The MAC header is of variable size and consists of the following fields: 

- 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 tables 6.2.1-1 and 6.2.1-2 for the 

DL and UL-SCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding 

included in the MAC PDU. The LCID field size is 5 bits; 

- L: The Length field indicates the length of the corresponding MAC SDU or MAC control element in bytes. 

There is one L field per MAC PDU subheader except for the last subheader and sub-headers corresponding to 

fixed-sized MAC control elements. The size of the L field is indicated by the F field; 

- F: The Format field indicates the size of the Length field as indicated in table 6.2.1-3. There is one F field per 

MAC PDU subheader except for the last subheader and sub-headers corresponding to fixed-sized MAC control 

elements. The size of the F field is 1 bit. If the size of the MAC SDU or MAC control element is less than 128 

bytes, the UE shall set the value of the F field to 0, otherwise the UE shall set it to 1; 

- E: The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set 

to "1" to indicate another set of at least R/R/E/LCID fields. The E field is set to "0" to indicate that either a MAC 

SDU, a MAC control element or padding starts at the next byte; 

- R: Reserved bits. 

The MAC header and sub-headers are octet aligned. 

Table 6.2.1-1 Values of LCID for DL-SCH 

Index LCID values 

00000 CCCH 

00001-xxxxx Identity of the logical channel 

xxxxx-11011 Reserved 

11100 UE Contention Resolution Identity 

11101 Timing Advance 

11110 DRX Command 

11111 Padding 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 30 of 34
3GPP 

Release 8 30 3GPP TS 36.321 V8.2.0 (2008-05) 

Table 6.2.1-2 Values of LCID for UL-SCH 

Index LCID values 

00000 CCCH 

00001-yyyyy Identity of the logical channel 

yyyyy-11010 Reserved 

11011 Power Headroom Report 

11100 C-RNTI 

11101 Short Buffer Status Report 

11110 Long Buffer Status Report 

11111 Padding 

Table 6.2.1-3 Values of F field: 

Index Size of Length field (in bits) 

0 7 

1 15 

Editor’s note: It is FFS whether this MAC header applies only to DL/UL SCH or also to other transport channels. 

Editor’s note: xxxxx and yyyyy are FFS 

6.2.2 MAC header for Random Access Response 

The MAC header is of variable size and consists of the following fields: 

- E: The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set 

to "1" to indicate another set of at least E/T/RAPID or E/T/R/R/BI fields. The E field is set to "0" to indicate that 

a MAC RAR starts at the next byte; 

- T: The Type field is a flag indicating whether the MAC subheader contains a Random Access ID or a Backoff 

Indicator. The T field is set to “0” to indicate the presence of a Backoff Indicator field in the subheader (BI). The 

T field is set to “1” to indicate the presence of a Random Access Preamble ID field in the subheader (RAPID); 

- R: Reserved bit; 

- BI: The Backoff Indicator field identifies the overload condition in the cell. The size of the BI field is 4 bits; 

- RAPID: The Random Access Preamble IDentitfier field identifies the transmitted Random Access Preamble (see 

subclause 5.1.3). The size of the RAPID field is 6 bits. 

The MAC header and sub-headers are octet aligned. 

6.2.3 MAC payload for Random Access Response 

The MAC RAR is of [fixed] size and consists of the following fields: 

- TA: The Timing Advance field indicates the required adjustment to the uplink transmission timing to be used for 

timing synchronisation (see subclause 4.2.4 of [2]). The size of the TA field is [11] bits; 

- UL Grant: The UpLink Grant field indicates the resources to be used on the uplink. The size of the UL Grant 

field is [21] bits; 

- Temporary C-RNTI: The Temporary C-RNTI field indicates the temporary identity that is used by the UE during 

Random Access. The size of the Temporary C-RNTI field is 16 bits. 

The MAC RAR is octet aligned. 

Editor’s note: The size of the TA and UL Grant field is FFS 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 31 of 34
3GPP 

Release 8 31 3GPP TS 36.321 V8.2.0 (2008-05) 

7 Variables and constants 

Editor’s note: This subclause defines the variables and constants used by MAC. 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 32 of 34
3GPP 

Release 8 32 3GPP TS 36.321 V8.2.0 (2008-05) 

7.1 RNTI values 

RNTI values are presented in Table 7.1-1. 

Table 7.1-1: RNTI values. 

Value (hexa-decimal) RNTI 

FDD TDD 

0000-0009 0000-003B RA-RNTI 

000A-FFF2 003C-FFF2 C-RNTI, Semi-Persistent 

Scheduling C-RNTI and 

Temporary C-RNTI 

FFF3-FFFC Reserved for future use 

FFFE P-RNTI 

FFFF SI-RNTI 

7.2 Backoff Parameter values 

Backoff Parameter values are presented in Table 7.2-1. 

Table 7.2-1: Backoff Parameter values. 

Index Backoff Parameter value (ms) 

0 0 

1 10 

2 20 

3 30 

4 40 

5 60 

6 80 

7 120 

8 160 

9 240 

10 320 

11 480 

12 960 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 33 of 34
3GPP 

Release 8 33 3GPP TS 36.321 V8.2.0 (2008-05) 

Annex A (informative): 

Change history 

Change history

Date TSG # TSG Doc. CR Rev Subject/Comment Old New 

2007-06 RAN2#58

bis 

R2-072710 MAC Protocol Specification Baseline - 

2007-06 RAN2#58

bis 

R2-072912 Text Proposal for UL HARQ (Tdoc R2-072708) 

Text Proposal for DL HARQ (Tdoc R2-072707) 

Text Proposal for RACH procedure (Tdoc R2-072640) 

Text Proposal for Logical Channel prioritization (Tdoc R2-072643) 

0.1.0 

2007-06 RAN2#58

bis 

R2-072994 Basic MAC PDU structure (Tdoc R2-072983) with updates 

Agreements on time-frequency resource configuration (Tdoc R2-

072993) 

Agreement on RA-RNTI association (Tdoc R2-072993) 

Clarification on RA Response reception (Tdoc R2-072993) 

0.1.0 0.1.1 

2007-08 RAN2#59 R2-073715 Removed reference to non-existing table (Tdoc R2-073473) 

Incorrect mapping of logical to transport channel (Tdoc R2-073473) 

Un-necessary error checking in HARQ process procedure (Tdoc 

R2-073473) 

Removal of reference to timing relation for HARQ feedback (Tdoc 

R2-073473) 

Correction of Internal variable name (Tdoc R2-073473) 

Correction of procedure in case of successful HARQ reception 

(Tdoc R2-073473) 

0.1.1 0.2.0 

2007-09 RAN2#59 R2-073885 Text proposal for Random Access procedure 

Text proposal on HARQ clarification for TDD 

Text proposal on HARQ for grants 

0.2.0 0.2.1 

2007-09 RAN#37 RP-070688 Clean version for information 0.2.1 1.0.0 

2007-10 RAN2#59

bis 

R2-074530 Editorial update with Editor’s notes (Tdoc R2-074211). 1.0.0 1.1.0 

2007-11 RAN2#60 R2-075093 Agreements on MAC PDU format (R2-074536) 

Corrections on Random Access Procedure (R2-074536) 

1.1.0 1.1.1 

2007-11 RAN2#60 R2-075243 Endorsement of v1.1.1 

Removal of FFS on DL CCCH existence 

1.1.1 1.2.0 

2007-11 RAN2#60 R2-075488 Agreement on identity used Random Access Response (R2-

075038) 

Agreement on Local Nack1 (R2-074949) 

PUCCH Resource handling (R2-075432) 

UL HARQ agreements (R2-075432) 

Agreements on semi-persistent scheduling (R2-075432, 36.300) 

Agreements on BSR/SR triggers (R2-075432) 

Agreements on BSR contents (R2-075432) 

Agreements on Timing Advance principles (36.300) 

Agreements on DRX control (36.300) 

Handling of P-BCH, D-BCH, PCH (R2-075246) 

1.2.0 1.3.0 

2007-11 RAN #38 RP-070917 Clean version, presented at TSG RAN-38 for approval 1.3.0 2.0.0 

2007-12 RAN #38 - Approved at TSG RAN-38 and placed under change control 2.0.0 8.0.0 

2008-03 RAN #39 RP-080162 0001 2 CR to 36.321 with E-UTRA MAC protocol specification update 8.0.0 8.1.0 

2008-05 RAN #40 RP-080410 0002 1 36.321 CR covering agreements of RAN2 #61bis and RAN2#62 8.1.0 8.2.0 

Case 6:20-cv-00541-ADA Document 46-11 Filed 03/05/21 Page 34 of 34