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 y d Generation Partnership Project (3GPP .m) and may be further elaborated for the purposes of 3GPP.
`
`The present document has not been subject to any approval process by the 3GPPOrganizational 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.
`Evolved Wireless, LLC Exhibit 2006 — 001
`Apple/Microsoft v. Evolved Wireless IPR2016-01228
`
`

`
`SGPP TS 36.321 V8.2.0 {2008-O5}
`
`Keywords
`UMTS. radio
`
`3GPP
`
`Postai address
`
`3GPP support office address
`550 Route des Lucioles - Sophia Antipolis
`Valbonne - FRANCE
`Tel: +33 4 92 94 42 00 Fax: +33 4 93 65 47 ‘I6
`
`Internet
`
`http:!!\muw.3gpp.org
`
`Copyright Notification
`
`No part may be reproduced except as autl1o1'i7.ed by written permission.
`The copyright and the foregoing restriction extend to reproduction in all media.
`
`Q 2008, 3GPP Organizational Partners (ARIB, ATIS. CCSA, ETSI, '|"|'A, 'l"l'C).
`All rights reserved.
`
`ZTEIHTC
`Exhibit 1003-0002
`
`Exhibit 2006-O02
`
`Exhibit 2006-002
`
`

`
`3G!"-‘P TS 36.321 V8.2.0 (2008-O5}
`
`Contents
`
`Foreword
`
`l
`
`References
`
`Definitions and
`Definitions ....................................................................................................................................................... ..
`
`Services provided to upper layeis
`Services expected from physical Iayer..
`
`General .
`Introduction ............ ..
`MAC architecture
`MAC Entities
`
`4.l
`4.2
`4.2.]
`4.3
`4.3.]
`4.3.2
`4.4
`Channel structure............
`4.5
`TransportChannels
`4.5.1
`4.5.2 Logical
`4.5.3
`Mapping oi‘Transpon Channels to Logical Channels.
`4.5.3.1
`Uplink mapping ................................................... ..
`4.5.3.2
`Downlink
`
`..
`MAC procedures
`Random Access procedure......................................
`Random Access Procedure initialization...
`Random Access Resource selection
`Random Access Preamble transmission....
`Random Access Response reception.....
`Contention Resolution......................................
`Completion of the Random Access procedure .
`Maintenance of Uplink Time Alignment
`DL-SCH data transfer ............................ ..
`DL Assignment reception.
`HARQ operation
`
`5 5
`
`.
`5.
`S.
`5.
`5.
`5.
`5.
`5.
`
`HARQ
`Disassembly and dernultiplexing...
`UL-SCH data transfer .................................................................................................................................... ..
`UL Grant reception
`HARQ operation
`HARQ entity.......
`HARQ process...
`Multiplexing and assembly
`Logical channel prioritization...
`Multiplexing of MAC SDUS
`Scheduling Request ....... ..
`Buffer Status Reporting...........
`Power Headroom Reporting...
`PCH reception..............................
`BCI-l reception ........................... ..
`Discontinuous Reception [DRXJ .
`MAC reconfiguration ................. ..
`24
`MACReset
`Handling of unknown, unforeseen and erroneous protocol data .................................................................... .. 24
`
`ZTEIHTC
`Exhibit 1 003-0003
`
`Exhibit 2006-O03
`
`Exhibit 2006-003
`
`

`
`Release 8
`
`3GPP T5 36.321 VB.2.0 [2008-05]
`
`Protocol Data Units. formats and
`PnmocolUmlalJn“&HuHhuuunu“uuuuuHnnHU-
`
`mmmuumummumummmuu24
`24
`24
`MAC PDU (lJI.—SCH and
`26
`MACControl
`26
`Buffer Status Report MAC Control Elements.
`26
`C-RNTI MAC Control Element......................
`DRX Command MAC Control26
`UE Contention Resolution Identity MAC Control
`2?
`Timing Advance MAC Conuol
`.. 27
`Power Headroom MAC Control ElemenL.....
`2‘?
`MAC PDU {transparent MAC]
`28
`MAC PDU {Random Access
`28
`Formats and parameters...................................
`.....29
`MAC header for DL-SCH and UL-SC]-l........
`29
`MAC header for Random Access Response
`30
`MAC payload for Random Access Response
`30
`Variables and
`RNTI values.........................
`Backof‘f'Paramc1or
`
`.... .. 32
`32
`
`eemeweeemeoeoom
`
`~mbwvHwvww~H0\LJ'I41\a-|I~J—-
`
`.
`,
`6.2.
`6.2.3
`7
`7.]
`7.2
`
`Annex A (informative):
`
`Change
`
`ZTEIHTC
`Exhibit 1003-0004
`
`Exhibit 2006-O04
`
`Exhibit 2006-004
`
`

`
`3GF'P TS 35.321 V8.21) (2008-O5]
`
`Foreword
`
`This Technical Specification has been produced by the 3”‘ 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 rc—rcIeasecl by the TSG with an
`identifying change of release date and an increase in version number as Follows:
`
`Version x.y.z
`
`where:
`
`the first digit:
`
`1
`
`2
`
`3
`
`presented to TSG for information;
`
`presented to TSG for approval;
`
`or greater indicates TSG approved document under change control.
`
`the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
`updates, etc.
`
`the third digit is incremented when editorial only changes have been incorporated in the document.
`
`ZTEIHTC
`Exhibit 1003-0005
`
`Exhibit 2006-O05
`
`Exhibit 2006-005
`
`

`
`SGPP TS 35.321 V8.21) [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 ofthe 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 anon-specific reference, the latest version applies. In the case ofa reference to a3GPP document (including
`a GSM document). a non-specific reference implicitly refers to the latest version of that document in the some
`Release as the present document.
`
`3GPP TR 2 I .905: "Vocabulary for SGPP Specifications".
`
`3GPP TR 36.213: “Evolved Universal Terrestrial Radio Access [E-UTRA}; Physical Layer
`Procedures".
`
`3GPP TS 36.322: “Evolved Universal Terrestrial Radio Access [E-UTRA}; Radio Link Control
`{RLCJ protocol specification”.
`
`3GP? TS 36.323: “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data
`Convergence Protocol [PDCPJ Specification".
`
`3GP? TS 36.2 I2: “Evolved Universal Terrestrial Radio Access (E—UTRA); Multiplexing and
`channel coding".
`
`3GPP TS 36.214: “Evolved Universal Terrestrial Radio Access [E~UTRA); Physical layer;
`Measurements".
`
`3
`
`Definitions and abbreviations
`
`3.1
`
`Definitions
`
`For the purposes ofthe 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 ofthe same term, if any, in TR 21.905 [I].
`
`Active Time: time during which the UE monitors the PDCCH for a PDCCH-subframe. Section 5.? defines the
`conditions for which a subframe is included as partofActive Time.
`
`Contention Resolution Timer: Specifies the number ofeonsceutive l’DCCl—l-subframe[s) during which the UE shall
`monitor the PDCCI-[ 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 ofthe On Duration followed by a possible period ofinactivity (see figure
`3.l-| below).
`
`ZTEFHTC
`Exhibit 1003-0006
`
`Exhibit 2006-O06
`
`Exhibit 2006-006
`
`

`
`3GPP T5 36.321 V8.21] (2008-U5)
`
`_""'0-Fl Dumrfrm--9-:4---------------0pprrr:wrr'.'yfur DRX --
`Utishafl mon.‘.rol'
`FDCCH _’. -,
`
`' --
`[T-'-'
`
`Figure 3.1-1: DRX Cycle
`
`DRX Inactivity Timer: Specifies the number of consecutive PDCCH-subframe(s) afier successfully decoding a
`PDCCI-I 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 subfrarne(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 HA RQ 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 PDCCI-I 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.
`
`PDCCI-I-subfra me: For FDD UE operation. this represents any subframe; for TD D, only downlink subfiames.
`
`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 subfrdmes 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 2 I .905 [I] 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 [I].
`
`BSR
`C-RNTI
`
`CQI
`E-UTRA
`E-UTRAN
`MAC
`PH R
`P-RNTI
`RA-RNTI
`RNTI
`Sl—RNTl
`SR
`SRS
`TB
`
`Buffer Status Report
`Cell RNTI
`
`Channel Quality Indicator
`Evolved UMTS Terrestrial Radio Access
`Evolved UMTS Terrestrial Radio Access Network
`Medium Access Control
`Power Headroom Report
`Paging RNTI
`Random Access RNTI
`Radio Network Temporary Identifier
`System Information RNTI
`Scheduling Request
`Sounding Reference Symbols
`Transport Block
`
`ZTEJHTC
`Exhibit i003-000?
`
`Exhibit 2006-O07
`
`Exhibit 2006-007
`
`

`
`SGPP TS 36.321 V8.2.0 (2‘Dl}8-I}5)
`
`4
`
`General
`
`4.1
`
`Introduction
`
`The objective is to describe the MAC architecture and the MAC entity from a functional point ofview.
`
`4.2
`
`MAC architecture
`
`The description in this sub clause is a model and does not specify or restrict implementations.
`
`RRC is in control ofconfiguration of MAC.
`
`4.2.1
`
`MAC Entities
`
`E-UTRA defines two MAC entities; one in the U5 and one in the E-UTRAN. These MAC entities handle tl1e following
`transport channels:
`
`~ Broadcast Channel (BC!-l];
`
`- Downlink Shared Channel [DL-SCI-l);
`
`-
`
`Paging Channel [PC]-I];
`
`Uplink Shared Channel (UL-SCH};
`
`- Random Access Channe|(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 su blayer 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]-IARQ feedback;
`
`signalling ofscheduling Request;
`
`- measurements (e.g. Channel Quality Indication (CQIJ).
`
`The access to the data transfer services is through the use oftransport 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.
`
`ZTEEHTC
`Exhibit l003—000S
`
`Exhibit 2006-O08
`
`Exhibit 2006-008
`
`

`
`Release 3
`
`3GPP TS 36.321 V8.21] {Z008-O5]
`
`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 dificrcnt logical channels onto transport blocks (TB) to be delivered to
`the physical layer on transport channels;
`
`dc-multiplexing ofMAC SDUS fnorn 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 ofdynamic scheduling;
`
`priority handling between logical channels of one UE;
`
`Logical Channel pI'ioritisation;
`
`-
`
`transport format selection.
`
`NOTE: How the multiplexing relates to the (205 of the multiplexed logical channels is FFS.
`
`The location ofthc different functions and their relevance for uplink and downlink respectively is illustrated in Table
`4.4-].
`
`Table 4.4-1: MAC function location and link direction association.
`
`Uplink
`X
`X
`
`XXXXXXXX
`
`Downlink
`
`XX XX XXXXX
`
`eNB
`
`UE
`X
`X
`X
`
`X
`
`MAC function
`Mapping between logical channels and transport channels
`Multiplexing
`Demultiplexing
`
`Error correction through HARQ
`
`Transport Format Selection
`Priority handling between UEs
`Priority handling between logical channels of one UE
`Logical Channel prioritisation
`Scheduling information reporting
`
`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
`Broadcast Channel
`Downlink Shared Channel
`Paging Channel
`Uplink Shared Channel
`Random Access Channel
`
`Acronym
`BCH
`Di.-SCH
`PCH
`UL-SCH
`RACH
`
`Uplink
`
`Downlink
`X
`X
`X
`
`ZTEIHTC
`Exhibit 1003-0009
`
`Exhibit 2006-O09
`
`Exhibit 2006-009
`
`

`
`Release 8
`
`3GPP TS 36.321 V8.2.0 (2008-05)
`
`4.52
`
`Logical Channels
`
`The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for
`different kinds ofdata 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 452-1 below. When MAC uses the PDCCI-[ to indicate
`radio resource allocation, the RNTI that is mapped on the PDCCI-I 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-RNT] for Random Access Response on DL-SCI-1;
`
`Temporary C-RNTI for CCCI-I during the random access procedure;
`
`S]-RNTI For BCCI-l.
`
`Table 4.5.2-1: Logical channels provided by MAC.
`
`Logical channel name
`Broadcast Control Channel
`Paging Control Channel
`Common Control Channei
`Dedicated Control Channel
`Dedicated Traffic Channel
`
`Acronym
`BCCH
`PCCH
`CCCH
`DCCH
`DTCH
`
`Control channel
`
`Traffic channel
`
`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 uplinlr onto uplink transport channels. The uplink
`logical channels can be mapped as described in Figure 4.5.3.1-I and'I‘ab|e 4.5.3.1-1.
`
`ccci-i
`
`neon
`
`oren
`
`_
`Upilmlr
`Logical channel:
`
`UL-SCH
`
`Up!ink
`Transport channels
`
`Figure 4.5.3.1-‘l
`
`Table 4.5.3.1-1: Uplink channel mapping.
`
`Transport channel
`Logical channel
`CCCH
`DCCH
`DTCH
`
`UL-SCH
`
`X
`X
`X
`
`ZTEIHTC
`Exhibit i003-0010
`
`Exhibit 2006-O10
`
`Exhibit 2006-010
`
`

`
`Release 3
`
`3GPP TS 36.321 V8.21} [2008-D5)
`
`4.5.3.2
`
`Downlink mapping
`
`The MAC entity is responsible for mapping the downlink logical channels to down] ink transport channels. The
`downlink logical channels can be mapped as described in Figure 4.5.3.2-l and Table 4.5.3.2-1.
`
`PCCH
`
`BCCH
`
`CCCH
`
`DCCH
`
`DTCH
`
`Downlfnk
`Logical channels
`
`Down!ink
`
`Transport channels
`
`Figure 4.5.3.2-1
`
`Table 4.5.3.2-1: Downllnk channel mapping.
`
`ransport channel
`Logical channel
`BCCH
`PCCH
`CCCH
`DCCH
`DTCH
`
`EICH
`
`X
`
`PC H
`
`5
`
`MAC procedures
`
`5.1
`
`Random Access procedure
`
`5.1.1
`
`Random Access Procedure initialization
`
`The Random Access procedure described in this subciause is initiated by a PDCCI-l order or by the MAC sublayer
`itself. The PDCCI-l 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—RNTls.
`
`the groups of Random Access Preambles and the set of available Random Access Preambles in each group.
`
`the thresholds required for selecting one ofthe 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 PREAEVlBl.E_TRANS_MAX [integer > 0].
`
`the initial preamble power PREAMBLE_ IN[TlAL_RECEIVED_TARGET_POWER.
`
`-
`
`the parameter Maximum number of Message?» HA RQ transmissions.
`
`[Note that the above parameters may be updated from higher layers before each Random Access procedure is initiated]
`
`ZTEEI-[TC
`Exhibit 1003-001}
`
`Exhibit 2006-011
`
`Exhibit 2006-011
`
`

`
`Release 8
`
`12
`
`3GPP T5 36.321 V8.23 (2003-05)
`
`The Random Access procedure shall be performed as follows:
`
`-
`
`Flush the [Message3] buffer;
`
`set the PREAMl3LE_TRANSMISSION_COUNTER to 1;
`
`set the backoffparameter value in the UE to 0 ms;
`
`-
`
`proceed to the selection ofthe Random Access Resource (see subclause 5. L2}.
`
`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:
`
`-
`
`Ifthe 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 ofthe Random Access Preamble (see subclause 5. L3).
`
`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 lhe two groups of Random Access
`Preambles configured by RRC.
`
`else, ifthe 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 ofthe allowed selections can be chosen with equal probability;
`
`if more than one PRACI-I resources are available in the same subframe (TDD), randomly select one. The
`random function shall be such that each ofthe allowed selections can be chosen with equal probability;
`
`proceed to the transmission of the Random Access Preamble [see subciause S. l .3].
`
`5.1.3
`
`Random Access Preamble transmission
`
`The random-access procedure shall be performed as follows:
`
`-
`
`lfi’REAMBl..E_TRANSMlSS[0N_COUNTER = PREAMBL.E_'i'RANS_MAX + 1:
`
`-
`
`indicate a Random Access problem to upper layers.
`
`set the parameter PREAMBLE_R.ECEIVED_TARG ET_POWER to
`PRE.AMBLl£_IN[TIAL_RE.CElV'ED__TARGE’l‘__POWER + (PREAMBLE_"lRANSMlSS[0N_COUN'l‘ER— I) *
`POWl:‘R_RAMP_S'l‘EP;]
`
`determine the next available Random Access occasion;
`
`instruct the physical layer to transmit a preamble using the selected PRACI-I resource, corresponding RA-RNTI,
`preamble index and PREAMBLE_RECEIVED_’l‘ARCi ET_POWER.
`
`ZTEIHTC
`Exhibit I003-0012
`
`Exhibit 2006-O12
`
`Exhibit 2006-012
`
`

`
`Release 8
`
`13
`
`3GPP TS 36.321 V3.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—RNTl
`defined below in the TTI window [RA_WIN DOW_B F.GfN—RA_Wl:\lDOW_EN D] for Random Access Responsets)
`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- RN Tl= t_id+ l0*f_i d
`
`Where t_id is the index of the first subframe ofthe specified PRACH resource [05 t__id <lt]), and f_id is the index ofthe
`specified PRACH rcsou1'ce within that subframe, in ascending order of frequency domain (GS f_id< 6). The UF. may
`stop monitoring for Random Access Response(s} afler 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:
`
`-
`
`ifthe Random Access Response contains a Backoff Indicator subheader:
`
`-
`
`set the backoffparameter value in the UE as indicated by the BI field ofthc Backofflndicator subheadcr
`and Table 7.2-l.
`
`else, set the hacker1” parameter value in the UE to 0 ms.
`
`ifthe Random Access Response contains a Random Access Preamble identifier corresponding to the
`transmitted Random Access Preamble (see subclause 5.l.3}. the UE shall:
`
`-
`
`consider this Random Access Response reception successful;
`
`process the received Timing Alignment value (see subelause 5.2);
`
`process the received UI. grant value;
`
`ifthe 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 ofthe first transmission eon'esponding to the UL grant provided in the Random
`Access Response message;
`
`iflhis is the first successfully received Random Access Response within this Random Access
`procedure:
`
`-
`
`ifthe UE is in RRC_CONNECTF.D 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.
`
`When an uplink transmission is required, c,g., for contention resolution. the eNB should not provide a
`grant smaller than 80 bits in the Random Access Response.
`
`lfwithin a Random Access procedure, an uplink grant provided in the Random Access Response for the
`same group ofRandom Access Preambles has a different size than the first uplink grant allocated during
`that Random Access procedure, the UE behavior is not defined.
`
`lfno Random Access Response is received within the TTI window [RA_Wl'.\lDOW‘BF.G|N—RA_WlNDOW_END],
`or ifall 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 UP.
`shall:
`
`-
`
`if the Random Access procedure was initiated by the MAC stlblayet‘ itself‘; or
`
`ZTEIHTC
`Exhibit 1003-0013
`
`Exhibit 2006-O13
`
`Exhibit 2006-013
`
`

`
`Release 3
`
`14
`
`3GPP TS 36.321 V8.20 (2003-U5)
`
`-
`
`if the Random Access procedure was initiated by a PDCCH order and the
`PREAMBLE_TRANSMISSlON_COUNTER is iess than PREAMBI.E_TRAl‘~lS_MAX:
`
`-
`
`-
`
`increment PREAMB1.E_TRANSMl SS[0N_COUNTER by I;
`
`ifin 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 backotfparameter in the UE, compute and apply a backoifvaluc indicating when a new
`Random Access transmission shall be attempted:
`
`— proceed to the selection ol‘a Random Access Resource (see subclause 5.1.2).
`
`l"-Editor's note: \l\-"|1cthci' error conditions are specified is J"-‘F3.
`
`5.1.5
`
`Contention Resolution
`
`Contention Resolution is based on C-RNTI on PDCCH and U13 Contention Resolution identity on Dl.-SCH"
`
`Once the uplink message containing the C-RNTI MAC control element or the uplink message including the CCCH
`S131] is transmitted, the UE shall.
`
`-
`
`start the Contention Resolution Ti met;
`
`monitor the PDCCH until the Contention Resolution Timer expires;
`
`ifnotification ofa reception ofa PDCCH transmission is received from lower layers, the UE shall:
`
`—
`
`ifthe C—RNTI MAC control element was included in uplink message:
`
`-
`
`ifthc Random Access procedure was initiated by the MAC sublaycr 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 PDCCI-I order and the PDCCH transmission is
`addressed to the C—RNTl:
`
`-
`
`consider this Contention Resolution successful;
`
`stop the Contention Resolution Timer;
`
`discard the Temporary C-RNTI;
`
`-
`
`consider this Random Access procedure successfully completed.
`
`-
`
`else ifthe uplink message includes the CCCH SDU and the PDCCI-I transmission is addressed to its
`Temporary C-RNTI:
`
`—
`
`ifthe MAC PDU is successfully decoded:
`
`-
`
`-
`
`-
`
`stop the Contention Resolution Timer;
`
`ifthe MAC PDU contains a UE Contention Resolution Identity MAC control element; and
`
`ifthe UE Contention Resolution Identity included in the MAC control element matches the CCCI--I
`SDU transmitted in the uplink message:
`
`-
`
`consider this Contention Resolution successful and finish the disasscmbly 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.
`
`ZTEIHTC
`Exhibit l003—00l 4
`
`Exhibit 2006-O14
`
`Exhibit 2006-014
`
`

`
`Release 8
`
`3GPP TS 36.321 V8.20 (2003-D5}
`
`-
`
`-
`
`else
`
`-
`
`consider this Contention Resolution not successful and discard the successfully decoded MAC
`PDU.
`
`discard the Temporary C-RNTI.
`
`-
`
`-
`
`ifthe Contention Resolution Timer expires:
`
`-
`
`consider the Contention Resolution not successful.
`
`ifthe Contention Resolution is considered not successful the UE shall:
`
`-
`
`ifthe Random Access procedure was initiated by the MAC sublayer itself; or
`
`ifthe Random Access procedure was initiated by a PDCCH order and the
`PREAlVlBLE_TRANSMISSION_COUN'l"ER is less than PREAMBLF._TRANS_MAX:
`
`~
`
`-
`
`—
`
`increment l’REAMBI,E_TRANSMiSSl0N_C()UNTER by 1;
`
`based on the backoffparameter 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:
`
`v
`
`if the PRP.-‘.AMBl.E_TRAN SMlSSiON_COU'N'lT£R is greater than PRl:‘AMBLE_TRANS_MAX:
`
`-
`
`indicate recovery from a Random Access problem to upper layers.
`
`5.2
`
`Maintenance of Uplink Time Alignment
`
`The UE has a configurable ‘lime Alignment Timer. The Time Alignment Timer is valid only in the cell for which it was
`configured and started.
`
`lfthe 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 (ifalready running].
`
`- when a Time Alignment Command is received in a Random Access Response message:
`
`-
`
`ifthe Random Access Preamble and PRACH resource were explicitly signalled:
`
`-
`
`—
`
`apply the Time Alignment Command;
`
`start the Time Alignment Timer (ifnot running] or restart the Time Alignment Timer {ifalready running).
`
`else, ifthe 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. L5. stop the Time
`Alignment Timer.
`
`else:
`
`ZTEIHTC
`
`Exhibit 1003-0015
`
`Exhibit 2006-O15
`
`Exhibit 2006-015
`
`

`
`16
`
`3GPP TS 36.321 V8.21} (2008-D5}
`
`-
`
`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 PUCCI-l resources;
`
`release any assigned SRS resources.
`
`5.3
`
`DL-SCH data transfer
`
`Editor's note: C ttrrcttt text applies to, at least, F DD.
`
`5.3.1
`
`DL Assignment reception
`
`ll-Editor's note: A downlink assignrnent can relate to one or two IMLMU) '|'l‘3s. It is I"!-‘S how this inI"onnation is
`pic-scttted to MAC.
`
`When the UE has aC-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 D1, assignment has been configured:
`
`-
`
`-
`
`ifa downlink assignment for this TTI has been received on the PDCCH for the UE’s C-RNTI, Temporary
`C-RNTI or RA-RNTI:
`
`-
`
`indicate adownlink assignment and the associated I-IARQ information to the HARQ entity for this TTI.
`
`else, it'a downlink assignment for this TTI has been configured:
`
`-
`
`indicate a downlink assignment, for a new transmission, and the associated I-IARQ information to the HA RQ
`entity for this ’lTl.
`
`When the UE needs to read BCCH, the UE shall:
`
`-
`
`ifadownlink assignment for this TTI has been received on the PDCCI-l for the SI-RNTI;
`
`-
`
`indicate adownlink amignment for the dedicated broadcast HARQ process to the I-IARQ entity for this TTI.
`
`NOTE: Downlink assignments for both C-RNTI and SI-RNTI can be received in the same TTI.
`
`is con|"tgur-ed. as needed, b_\-' upper layers or MAC‘ [I3-‘F31 to monitor PDCICE-I for t'.‘-R.N't'|, and by
`|'iditor’s note: 1...]
`e_\-i.&\(‘ to monitor PDCICI-I for 'l‘ctnpor;try C~RNTl and RA—Ri\‘=Tl.
`
`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 HA RQ 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 I-IARQ processes are used in the UE to support the HARQ entity. [The ntunber 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 l-IARQ process. the UE shall:
`
`ZTEKHTC
`Exhibit 1003-OOI 6
`
`Exhibit 2006-O16
`
`Exhibit 2006-016
`
`

`
`Release 8
`
`17
`
`SGPP TS 36.321 V8.21} [2008-05]
`
`-
`
`allocate the received TB to the broadcast HARQ process.
`
`NOTE:
`
`In case of BCCH a dedicated broadcast HARQ process is used.
`
`HARQ process
`5.3.2.2
`For each received TB:
`
`-
`
`if the NDI, when provided, has been incremented compared to the value of the previous received transmission
`for this HA RQ process; or
`
`if the l-IARQ process is equal to the broadcast process and the physical layer indicates a new transmission; or
`
`ifthis is the very first received transmission for this l-IARQ process:
`
`-
`
`a new transmission is indicated for this I-IARQ process.
`
`-
`
`else, a retransmission is indicated for this HARQ process.
`
`The UE then shall:
`
`-
`
`ifa new transmission is indicated for this l-IARQ process:
`
`-
`
`replace the data currently in the soft buffer for this HARQ process with the received data.
`
`ifa retransmission is indicated For this l-IARQ process:
`
`—
`
`-
`
`ifthe data has notyct been successfully decoded:
`
`-
`
`combine the received data with the data currently in the soft buffer for this HARQ process.
`
`ifthe 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:
`
`ifthe 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) ofthc 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—RN'l'l; or
`
`ifthe HARQ process is associated with a transmission indicated with a Temporary C-RNTI and a UE Contention
`Resolution Identity match is not indicated; or
`
`ifthe HARQ proc