EXHIBIT C

Case 6:20-cv-00541-ADA Document 46-8 Filed 03/05/21 Page 1 of 107
3GPP TS 36.300 V8.1.0 (2007-06)

Technical Specification 

3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;

Evolved Universal Terrestrial Radio Access (E-UTRA)

and Evolved Universal Terrestrial Radio Access Network

(E-UTRAN);

Overall description;

Stage 2

(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-8 Filed 03/05/21 Page 2 of 107
3GPP 

Release 8 2 3GPP TS 36.300 V8.1.0 (2007-06)

Keywords 

UMTS, stage 2, radio, architecture 

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. 

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

All rights reserved. 

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

Release 8 3 3GPP TS 36.300 V8.1.0 (2007-06)

Contents 

Foreword ............................................................................................................................................................ 9

1 Scope ...................................................................................................................................................... 10

2 References .............................................................................................................................................. 10

3 Definitions, symbols and abbreviations ................................................................................................. 10

3.1 Definitions ........................................................................................................................................................... 10

3.2 Abbreviations ...................................................................................................................................................... 11

4 Overall architecture ................................................................................................................................ 12

4.1 Functional Split ................................................................................................................................................... 13

4.2 Interfaces ............................................................................................................................................................. 14

4.2.1 S1 Interface .................................................................................................................................................... 14

4.2.2 X2 Interface ................................................................................................................................................... 14

4.3 Radio Protocol architecture ................................................................................................................................ 14

4.3.1 User plane ...................................................................................................................................................... 14

4.3.2 Control plane ................................................................................................................................................. 15

4.4 Synchronization ................................................................................................................................................... 16

4.5 IP fragmentation ................................................................................................................................................. 16

5 Physical Layer for E-UTRA ................................................................................................................... 16

5.1 Downlink Transmission Scheme ........................................................................................................................ 17

5.1.1 Basic transmission scheme based on OFDM................................................................................................ 17

5.1.2 Physical-layer processing ............................................................................................................................. 17

5.1.3 Physical downlink control channel ............................................................................................................... 18

5.1.4 Downlink Reference signal ........................................................................................................................... 18

5.1.5 Downlink multi-antenna transmission .......................................................................................................... 18

5.1.6 MBSFN transmission .................................................................................................................................... 19

5.1.7 Physical layer procedure ............................................................................................................................... 19

5.1.7.1 Link adaptation ........................................................................................................................................ 19

5.1.7.2 Power Control .......................................................................................................................................... 19

5.1.7.3 Cell search ............................................................................................................................................... 19

5.1.8 Physical layer measurements definition ....................................................................................................... 19

5.2 Uplink Transmission Scheme ............................................................................................................................. 19

5.2.1 Basic transmission scheme ............................................................................................................................ 19

5.2.2 Physical-layer processing ............................................................................................................................. 20

5.2.3 Physical uplink control channel .................................................................................................................... 20

5.2.4 Uplink Reference signal ................................................................................................................................ 21

5.2.5 Random access preamble .............................................................................................................................. 21

5.2.6 Uplink multi-antenna transmission ............................................................................................................... 21

5.2.7 Physical channel procedure ........................................................................................................................... 21

5.2.7.1 Link adaptation ........................................................................................................................................ 21

5.2.7.2 Uplink Power control .............................................................................................................................. 21

5.2.7.3 Uplink timing control .............................................................................................................................. 21

5.3 Transport Channels ............................................................................................................................................. 22

5.3.1 Mapping between transport channels and physical channels ....................................................................... 23

5.4 E-UTRA physical layer model ............................................................................................................................ 23

5.4.1 Physical-layer model of E-UTRA transport channels .................................................................................. 24

5.4.1.1 Downlink-Shared Channel ...................................................................................................................... 24

5.4.1.2 Broadcast Channel ................................................................................................................................... 25

5.4.1.3 Paging Channel ........................................................................................................................................ 26

5.4.1.4 Multicast Channel .................................................................................................................................... 27

5.4.1.5 Uplink Shared Channel............................................................................................................................ 28

5.4.1.6 Random-access Channel .......................................................................................................................... 29

5.4.2 Physical-layer indications ............................................................................................................................. 29

5.4.2.1 Error indicators ........................................................................................................................................ 30

5.4.2.2 Channel-quality indicators ...................................................................................................................... 30

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

Release 8 4 3GPP TS 36.300 V8.1.0 (2007-06)

6 Layer 2 ................................................................................................................................................... 30

6.1 MAC Sublayer .................................................................................................................................................... 31

6.1.1 Services and Functions .................................................................................................................................. 31

6.1.2 Logical Channels ........................................................................................................................................... 31

6.1.2.1 Control Channels ............................................................................................................................... 32

6.1.2.2 Traffic Channels ...................................................................................................................................... 32

6.1.3 Mapping between logical channels and transport channels ......................................................................... 32

6.1.3.1 Mapping in Uplink................................................................................................................................... 32

6.1.3.2 Mapping in Downlink .............................................................................................................................. 33

6.2 RLC Sublayer ...................................................................................................................................................... 34

6.2.1 Services and Functions .................................................................................................................................. 34

6.2.2 PDU Structure ............................................................................................................................................... 34

6.3 PDCP Sublayer .................................................................................................................................................... 35

6.3.1 Services and Functions .................................................................................................................................. 35

6.3.2 PDU Structure ............................................................................................................................................... 35

6.4 Data flows through Layer 2 ................................................................................................................................ 36

7 RRC ........................................................................................................................................................ 36

7.1 Services and Functions ....................................................................................................................................... 36

7.2 RRC protocol states & state transitions .............................................................................................................. 36

7.3 Transport of NAS messages ............................................................................................................................... 37

7.4 System Information ............................................................................................................................................. 37

7.5 RRC Procedures .................................................................................................................................................. 38

8 E-UTRAN identities ............................................................................................................................... 38

8.1 E-UTRAN related UE identities ......................................................................................................................... 38

8.2 Network entity related Identities ........................................................................................................................ 38

9 ARQ and HARQ .................................................................................................................................... 39

9.1 HARQ principles ................................................................................................................................................. 39

9.2 ARQ principles .................................................................................................................................................... 40

9.3 HARQ/ARQ interactions .................................................................................................................................... 40

10 Mobility .................................................................................................................................................. 40

10.1 Intra E-UTRAN ................................................................................................................................................... 40

10.1.1 Mobility Management in LTE_IDLE ........................................................................................................... 41

10.1.1.1 Cell selection ........................................................................................................................................... 41

10.1.1.2 Cell reselection ........................................................................................................................................ 41

10.1.1.3 Handling in eNB ...................................................................................................................................... 42

10.1.1.4 Handling above eNB ............................................................................................................................... 42

10.1.1.5 Mobility Management Entity (MME) ..................................................................................................... 42

10.1.2 Mobility Management in LTE_ACTIVE ..................................................................................................... 42

10.1.2.1 Handover .................................................................................................................................................. 42

10.1.2.1.1 C-plane handling ................................................................................................................................ 43

10.1.2.1.2 U-plane handling ..................................................................................................................................... 45

10.1.2.2 Path Switch .............................................................................................................................................. 46

10.1.2.3 Data forwarding ....................................................................................................................................... 46

10.1.2.4 Handling in eNB ...................................................................................................................................... 46

10.1.2.5 Handling above eNB ............................................................................................................................... 46

10.1.2.6 Mobility Management Entity (MME) ..................................................................................................... 46

10.1.2.7 Timing Advance ...................................................................................................................................... 46

10.1.3 Measurements ................................................................................................................................................ 47

10.1.3.1 Intra-frequency neighbour (cell) measurements ..................................................................................... 48

10.1.3.2 Inter-frequency neighbour (cell) measurements ..................................................................................... 48

10.1.4 Paging and C-plane establishment ................................................................................................................ 48

10.1.5 Random Access Procedure ............................................................................................................................ 48

10.1.5.1 Contention based random access procedure ........................................................................................... 49

10.1.5.2 Non-contention based random access procedure .................................................................................... 50

10.1.5.3 Interaction model between L1 and L2/3 for Random Access Procedure ............................................... 51

10.1.6 Radio Link Failure......................................................................................................................................... 51

10.1.7 Radio Access Network Sharing .................................................................................................................... 52

10.1.8 Handling of Roaming and Area Restrictions for UEs in LTE_ACTIVE .................................................... 53

10.2 Inter RAT ............................................................................................................................................................ 53

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

Release 8 5 3GPP TS 36.300 V8.1.0 (2007-06)

10.2.1 Cell reselection .............................................................................................................................................. 53

10.2.2 Handover ....................................................................................................................................................... 54

10.2.3 Measurements ................................................................................................................................................ 54

10.2.3.1 Inter-RAT handovers from E-UTRAN ................................................................................................... 54

10.2.3.2 Inter-RAT handovers to E-UTRAN ........................................................................................................ 54

10.2.3.3 Inter-RAT cell reselection from E-UTRAN ........................................................................................... 55

10.2.3.4 Limiting measurement load at UE .......................................................................................................... 55

10.2.4 Network Aspects ........................................................................................................................................... 55

10.3 Inter 3GPP access system mobility..................................................................................................................... 55

10.3.1 Cell reselection .............................................................................................................................................. 55

10.3.2 Handover ....................................................................................................................................................... 55

10.3.3 Measurements ................................................................................................................................................ 55

10.4 Area Restrictions ................................................................................................................................................. 55

11 Scheduling and Rate Control .................................................................................................................. 55

11.1 Basic Scheduler Operation .................................................................................................................................. 56

11.1.1 Downlink Scheduling .................................................................................................................................... 56

11.1.2 Uplink Scheduling ......................................................................................................................................... 56

11.2 Void ..................................................................................................................................................................... 56

11.3 Measurements to Support Scheduler Operation ................................................................................................. 56

11.4 Rate Control of GBR, MBR, and AMBR ........................................................................................................... 57

11.4.1 Downlink ....................................................................................................................................................... 57

11.4.2 Uplink ............................................................................................................................................................ 57

12 DRX in RRC_CONNECTED ................................................................................................................ 57

13 QoS ......................................................................................................................................................... 58

13.1 QoS concept and bearer service architecture ...................................................................................................... 58

13.2 Resource establishment and QoS signalling ....................................................................................................... 59

14 Security .................................................................................................................................................. 59

14.1 Overview and Principles ..................................................................................................................................... 59

14.2 Security termination points ................................................................................................................................. 60

15 MBMS .................................................................................................................................................... 60

15.1 General ................................................................................................................................................................ 61

15.2 MBMS Cells ........................................................................................................................................................ 62

15.2.1 MBMS-dedicated cell ................................................................................................................................... 62

15.2.2 MBMS/Unicast-mixed cell ........................................................................................................................... 62

15.3 MBMS Transmission .......................................................................................................................................... 63

15.3.1 General ........................................................................................................................................................... 63

15.3.2 Single-cell transmission ................................................................................................................................ 63

15.3.3 Multi-cell transmission .................................................................................................................................. 63

15.3.4 MBMS Reception States ............................................................................................................................... 64

16 Radio Resource Management aspects .................................................................................................... 65

16.1 RRM functions .................................................................................................................................................... 65

16.1.1 Radio Bearer Control (RBC) ......................................................................................................................... 65

16.1.2 Radio Admission Control (RAC) .................................................................................................................. 65

16.1.3 Connection Mobility Control (CMC) ........................................................................................................... 65

16.1.4 Dynamic Resource Allocation (DRA) - Packet Scheduling (PS) ................................................................ 65

16.1.5 Inter-cell Interference Coordination (ICIC) .................................................................................................. 66

16.1.6 Load Balancing (LB) ..................................................................................................................................... 66

16.1.7 Inter-RAT Radio Resource Management ..................................................................................................... 66

16.2 RRM architecture ................................................................................................................................................ 66

16.2.1 Centralised Handling of certain RRM Functions ......................................................................................... 66

16.2.2 De-Centralised RRM ..................................................................................................................................... 66

16.2.3 Load balancing control .................................................................................................................................. 66

17 RF aspects .............................................................................................................................................. 66

17.1 Spectrum deployments ........................................................................................................................................ 66

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

Release 8 6 3GPP TS 36.300 V8.1.0 (2007-06)

18 UE capabilities ....................................................................................................................................... 66

19 S1 Interface ............................................................................................................................................ 67

19.1 S1 User plane ...................................................................................................................................................... 67

19.2 S1 Control Plane ................................................................................................................................................. 67

19.2.1 S1 Interface Functions ................................................................................................................................... 68

19.2.1.1 S1 Paging function................................................................................................................................... 68

19.2.1.2 S1 UE Context Management function .................................................................................................... 68

19.2.1.3 Initial Context Setup Function ................................................................................................................ 68

19.2.1.4 Mobility Functions for UEs in LTE_ACTIVE ....................................................................................... 69

19.2.1.4.1 Intra-LTE Handover .......................................................................................................................... 69

19.2.1.4.2 Inter-3GPP-RAT Handover .............................................................................................................. 69

19.2.1.5 SAE Bearer Service Management function ............................................................................................ 69

19.2.1.6 NAS Signalling Transport function ........................................................................................................ 69

19.2.1.7 NAS Node Selection Function ............................................................................................................... 69

19.2.2 S1 Interface Signalling Procedures ............................................................................................................... 69

19.2.2.1 Paging procedure ..................................................................................................................................... 70

19.2.2.2 S1 UE Context Release procedure .......................................................................................................... 70

19.2.2.2.1 S1 UE Context Release (EPC triggered) ........................................................................................... 70

19.2.2.2.2 S1 UE Context Release Request (eNB triggered) ............................................................................. 71

19.2.2.3 Initial Context Setup procedure............................................................................................................... 71

19.2.2.4 SAE Bearer signalling procedures .......................................................................................................... 72

19.2.2.4.1 SAE Bearer Setup procedure ............................................................................................................. 72

19.2.2.4.2 SAE Bearer Modification procedure ................................................................................................. 73

19.2.2.4.3 SAE Bearer Release procedure (MME initiated) .............................................................................. 73

19.2.2.4.4 SAE Bearer Release procedure (eNB initiated) ................................................................................ 74

19.2.2.5 Handover signalling procedures .............................................................................................................. 74

19.2.2.5.1 Handover Preparation procedure ....................................................................................................... 75

19.2.2.5.2 Handover Resource Allocation procedure ........................................................................................ 75

19.2.2.5.3 Handover Completion procedure ...................................................................................................... 76

19.2.2.5.4 Handover Cancellation ...................................................................................................................... 76

19.2.2.6 NAS transport procedures ....................................................................................................................... 76

20 X2 Interface ............................................................................................................................................ 78

20.1 User Plane ........................................................................................................................................................... 78

20.2 Control Plane ....................................................................................................................................................... 78

20.2.1 X2-CP Functions ........................................................................................................................................... 79

20.2.2 X2-CP Procedures ......................................................................................................................................... 79

20.2.3 Inter-cell Load Management ......................................................................................................................... 79

21 System and Terminal complexity ........................................................................................................... 80

21.1 Overall System complexity ................................................................................................................................. 80

21.2 Physical layer complexity ................................................................................................................................... 80

21.3 UE complexity .................................................................................................................................................... 80

22 Support for self-configuration and self-optimisation ............................................................................. 80

22.1 Definitions ........................................................................................................................................................... 80

22.2 UE Support for self-configuration and self-optimisation ................................................................................... 81

22.3 Self-configuration ............................................................................................................................................... 82

22.3.1 Dynamic configuration of the S1-MME interface ........................................................................................ 82

22.3.1.1 Prerequisites ............................................................................................................................................. 82

22.3.1.2 SCTP initialization .................................................................................................................................. 82

22.3.1.3 Application layer initialization ................................................................................................................ 82

23 Others ..................................................................................................................................................... 82

23.1 Support for real time IMS services ..................................................................................................................... 82

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

Release 8 7 3GPP TS 36.300 V8.1.0 (2007-06)

Annex A (informative): NAS Overview ........................................................................................................ 83

A.1 Services and Functions ........................................................................................................................... 83

A.2 NAS protocol states & state transitions .................................................................................................. 83

Annex B (informative): MAC and RRC Control ......................................................................................... 85

B.1 Difference between MAC and RRC control .......................................................................................... 85

B.2 Classification of MAC and RRC control functions ................................................................................ 85

Annex C (informative): System Information ............................................................................................... 86

C.1 SI classification ...................................................................................................................................... 86

C.1.1 Information valid across multiple cells .............................................................................................................. 86

C.1.2 Information needed at cell/PLMN search ........................................................................................................... 86

C.1.3 Information needed prior to cell camping .......................................................................................................... 87

C.1.4 Information needed prior to cell access .............................................................................................................. 87

C.1.5 Information needed while camping on a cell ..................................................................................................... 88

C.1.6 Thoughts about category division ....................................................................................................................... 89

C.2 Division of SI between static and flexible parts ..................................................................................... 89

C.2.1 Static part ............................................................................................................................................................. 89

C.2.2 Flexible part ......................................................................................................................................................... 90

C.2.3 Information whose location is FFS ................................................................................................................... 91

C.2.4 Dedicated part ..................................................................................................................................................... 91

Annex D (informative): MBMS ..................................................................................................................... 92

D.1 MBMS control & functions ................................................................................................................................ 92

D.2 MBMS transmission ........................................................................................................................................... 92

D.3 Deployment Scenarios ........................................................................................................................................ 93

Annex E (informative): Drivers for Mobility Control ................................................................................. 94

E.1 Drivers ................................................................................................................................................................. 94

E.1.1 Best radio condition ...................................................................................................................................... 95

E.1.2 Camp load balancing ..................................................................................................................................... 95

E.1.3 Traffic load balancing ................................................................................................................................... 95

E.1.4 UE capability ................................................................................................................................................. 95

E.1.5 Hierarchical cell structures ............................................................................................................................ 95

E.1.6 Network sharing ............................................................................................................................................ 96

E.1.7 Private networks/home cells ......................................................................................................................... 96

E.1.8 Subscription based mobility control ............................................................................................................. 96

E.1.9 Service based mobility control ...................................................................................................................... 96

E.1.10 MBMS ........................................................................................................................................................... 96

E.2 Limitations for mobility control ......................................................................................................................... 96

E.2.1 UE battery saving .......................................................................................................................................... 96

E.2.2 Network signalling/processing load .............................................................................................................. 97

E.2.3 U-plane interruption and data loss ................................................................................................................ 97

E.2.4 OAM complexity ........................................................................................................................................... 97

E.3 Inter-frequency/RAT drivers .............................................................................................................................. 97

E.3.1 Mobility control during IDLE mode ............................................................................................................. 97

E.3.2 Mobility control upon IDLE to ACTIVE transition ..................................................................................... 98

E.3.3 Mobility control during ACTIVE mode ....................................................................................................... 99

E.3.4 Mobility control upon ACTIVE to IDLE transition ..................................................................................... 99

Annex F (informative): Mobility and Access Control Requirements associated with Closed 

Subscriber Group (CSG) Cells ................................................................... 101

F.1 Access Control .................................................................................................................................................. 101

F.2 Mobility ............................................................................................................................................................. 101

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

Release 8 8 3GPP TS 36.300 V8.1.0 (2007-06)

Annex G (informative): Guideline for E-UTRAN UE capabilities .......................................................... 102

Annex H (informative): L1/L2 Control Signalling Performance ............................................................. 103

Annex I (informative): Change history ...................................................................................................... 105

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

Release 8 9 3GPP TS 36.300 V8.1.0 (2007-06)

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-8 Filed 03/05/21 Page 10 of 107
3GPP 

Release 8 10 3GPP TS 36.300 V8.1.0 (2007-06)

1 Scope 

The present document provides an overview and overall description of the E-UTRAN radio interface protocol 

architecture. Details of the radio interface protocols will be specified in companion specifications of the 36 series. 

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 25.913: “Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (EUTRAN)” 

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

General description”. 

[4] 3GPP TS 36.211 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and 

Modulation . 

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

channel coding . 

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

procedures . 

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

Measurements 

[8] IETF RFC 2960 (10/2000): "Stream Control Transmission Protocol". 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Carrier frequency: center frequency of the cell. 

MBMS-dedicated cell: cell dedicated to MBMS transmission. 

Frequency layer: set of cells with the same carrier frequency. 

Handover: procedure that changes the serving cell of a UE in RRC_CONNECTED. 

Unicast/MBMS-mixed cell: cell supporting both unicast and MBMS transmissions. 

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

Release 8 11 3GPP TS 36.300 V8.1.0 (2007-06)

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]. 

ACK Acknowledgement 

ACLR Adjacent Channel Leakage Ratio 

AM Acknowledge Mode 

AMBR Aggregate Maximum Bit Rate 

ARQ Automatic Repeat Request 

AS Access Stratum 

BCCH Broadcast Control Channel 

BCH Broadcast Channel 

C/I Carrier-to-Interference Power Ratio 

CAZAC Constant Amplitude Zero Auto-Correlation 

CMC Connection Mobility Control 

CP Cyclic Prefix 

C-plane Control Plane 

CQI Channel Quality Indicator 

CRC Cyclic Redundancy Check 

DCCH Dedicated Control Channel 

DL Downlink 

DRX Discontinuous Reception 

DTCH Dedicated Traffic Channel 

DTX Discontinuous Transmission 

eNB E-UTRAN NodeB 

EPC Evolved Packet Core 

E-UTRA Evolved UTRA 

E-UTRAN Evolved UTRAN 

FDD Frequency Division Duplex 

FDM Frequency Division Multiplexing 

GERAN GSM EDGE Radio Access Network 

GNSS Global Navigation Satellite System 

GSM Global System for Mobile communication 

GBR Guaranteed Bit Rate 

HARQ Hybrid ARQ 

HO Handover 

HSDPA High Speed Downlink Packet Access 

ICIC Inter-Cell Interference Coordination 

IP Internet Protocol 

LB Load Balancing 

LCR Low Chip Rate 

LTE Long Term Evolution 

MAC Medium Access Control 

MBMS Multimedia Broadcast Multicast Service 

MBR Maximum Bit Rate 

MCCH Multicast Control Channel 

MCH Multicast Channel 

MCS Modulation and Coding Scheme 

MIMO Multiple Input Multiple Output 

MME Mobility Management Entity 

MTCH MBMS Traffic Channel 

NACK Negative Acknowledgement 

NAS Non-Access Stratum 

OFDM Orthogonal Frequency Division Multiplexing 

OFDMA Orthogonal Frequency Division Multiple Access 

PA Power Amplifier 

PAPR Peak-to-Average Power Ratio 

PBR Prioritised Bit Rate 

PCCH Paging Control Channel 

PDCP Packet Data Convergence Protocol 

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

Release 8 12 3GPP TS 36.300 V8.1.0 (2007-06)

PDU Packet Data Unit 

PHY Physical layer 

PLMN Public Land Mobile Network 

PRB Physical Resource Block 

PSC Packet Scheduling 

QAM Quadrature Amplitude Modulation 

QoS Quality of Service 

RAC Radio Admission Control 

RACH Random Access Channel 

RAT Radio Access Technology 

RB Radio Bearer 

RBC Radio Bearer Control 

RF Radio Frequency 

RLC Radio Link Control 

RNL Radio Network Layer 

ROHC Robust Header Compression 

RRC Radio Resource Control 

RRM Radio Resource Management 

RU Resource Unit 

S-GW Serving Gateway 

S1-MME S1 for the control plane 

S1-U S1 for the user plane 

SAE System Architecture Evolution 

SAP Service Access Point 

SC-FDMA Single Carrier – Frequency Division Multiple Access 

SCH Synchronization Channel 

SDMA Spatial Division Multiple Access 

SDU Service Data Unit 

SFN Single Frequency Network 

SU Scheduling Unit 

TA Tracking Area 

TB Transport Block 

TCP Transmission Control Protocol 

TDD Time Division Duplex 

TM Transparent Mode 

TNL Transport Network Layer 

TTI Transmission Time Interval 

UE User Equipment 

UL Uplink 

UM Un-acknowledge Mode 

UMTS Universal Mobile Telecommunication System 

U-plane User plane 

UTRA Universal Terrestrial Radio Access 

UTRAN Universal Terrestrial Radio Access Network 

VRB Virtual Resource Block 

X2-C X2-Control plane 

X2-U X2-User plane 

4 Overall architecture 

The E-UTRAN consists of eNBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) 

protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The 

eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME 

(Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U. 

The S1 interface supports a many-to-many relation between MMEs / Serving Gateways and eNBs. 

The EUTRAN architecture is illustrated in Figure 4 below. 

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

Release 8 13 3GPP TS 36.300 V8.1.0 (2007-06)

eNB

MME / S-GW MME / S-GW

eNB

eNB

X2

X2

X2

E-UTRAN

Figure 4: Overall Architecture 

4.1 Functional Split 

The eNB hosts the following functions: 

- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection 

Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling); 

- IP header compression and encryption of user data stream; 

- Selection of an MME at UE attachment; 

NOTE: it is assumed, that at UE attachment, firstly the MME is involved, i.e. actually the MME is selected. 

- Routing of User Plane data towards Serving Gateway; 

NOTE: it is FFS which node actually establishes the User Plane tunnel. 

NOTE: it is FFS whether User Plane tunnel establishment takes place together with the RRC activation. 

- Scheduling and transmission of paging messages (originated from the MME); 

- Scheduling and transmission of broadcast information (originated from the MME or O&M); 

- Measurement and measurement reporting configuration for mobility and scheduling. 

The MME hosts the following functions: 

- Distribution of paging messages to the eNBs; 

- Security control; 

- Idle state mobility control; 

- SAE bearer control; 

- Ciphering and integrity protection of NAS signalling. 

The Serving Gateway hosts the following functions: 

- Termination of U-plane packets for paging reasons (FFS); 

- Switching of U-plane for support of UE mobility. 

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

Release 8 14 3GPP TS 36.300 V8.1.0 (2007-06)

This is summarized on the figure below where yellow boxes depict the logical nodes, white boxes depict the functional 

entities of the control plane and blue boxes depict the radio protocol layers. 

NOTE: it is assumed that a logical E-UTRAN node in addition to the eNB is not needed for RRM purposes. 

Moreover, due to the different usage of inter-cell RRM functionalities, each inter-cell RRM functionality 

should be considered separately in order to assess whether it should be handled in a centralised manner or 

in a distributed manner. 

NOTE: MBMS related functions in E-UTRAN are described separately in subclause 15. 

internet

eNB

RB Control

Connection Mobility Cont.

eNB Measurement

Configuration & Provision

Dynamic Resource 

Allocation (Scheduler)

PDCP

PHY

MME

Serving Gateway

S1

MAC

Inter Cell RRM

Radio Admission Control

RLC

E-UTRAN EPC

RRC

Mobility Anchoring

SAE Bearer Control

Idle State Mobility 

Handling

NAS Security

Figure 4.1: Functional Split between E-UTRAN and EPC 

4.2 Interfaces 

4.2.1 S1 Interface 

4.2.2 X2 Interface 

4.3 Radio Protocol architecture 

In this subclause, the radio protocol architecture of E-UTRAN is given for the user plane and the control plane. 

4.3.1 User plane 

The figure below shows the protocol stack for the user-plane, where PDCP, RLC and MAC sublayers (terminated in 

eNB on the network side) perform the functions listed in subclause 6, e.g. header compression, ciphering, scheduling, 

ARQ and HARQ; 

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

Release 8 15 3GPP TS 36.300 V8.1.0 (2007-06)

eNB

PHY

UE

PHY

MAC

RLC

MAC

PDCP PDCP

RLC

Figure 4.3.1: User-plane protocol stack 

4.3.2 Control plane 

The figure below shows the protocol stack for the control-plane, where: 

- PDCP sublayer (terminated in eNB on the network side) performs the same security functions as for the user 

plane but does not perform header compression; 

- RLC and MAC sublayers (terminated in eNB on the network side) perform the same functions as for the user 

plane; 

- RRC (terminated in eNB on the network side) performs the functions listed in subclause 7, e.g.: 

- Broadcast; 

- Paging; 

- RRC connection management; 

- RB control; 

- Mobility functions; 

- UE measurement reporting and control. 

- NAS control protocol (terminated in MME on the network side) performs among other things: 

- SAE bearer management; 

- Authentication; 

- LTE_IDLE mobility handling; 

- Paging origination in LTE_IDLE; 

- Security control. 

NOTE: the NAS control protocol is not covered by the scope of this TS and is only mentioned for information. 

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

Release 8 16 3GPP TS 36.300 V8.1.0 (2007-06)

eNB

PHY

UE

PHY

MAC

RLC

MAC

MME

RLC

NAS NAS

RRC RRC

PDCP PDCP

Figure 4.3.2: Control-plane protocol stack 

4.4 Synchronization 

Diverse methods and techniques are preferred depending on synchronization requirements. As no single method can 

cover all E-UTRAN applications a logical port at eNB may be used for reception of timing input independent of 

synchronization method chosen. 

4.5 IP fragmentation 

Fragmentation function in IP layer on S1 and X2 shall be supported. 

Configuration of S1-U (X2-U) link MTU in the eNB/SAE GW according to the MTU of the network domain the node 

belongs to shall be considered as a choice at network deployment. The network may employ various methods to handle 

IP fragmentation, but the specific methods to use are implementation dependant. 

At the establishment/modification of a SAE bearer, the network may signal a value that to be used as MTU by the UE 

IP stack (it is FFS how the requirement on the UE should be formulated). It is also FFS if the MTU is signaled by the 

MME or the eNB. 

5 Physical Layer for E-UTRA 

The generic frame structure is illustrated in Figure 5.1-1. Each 10 ms radio frame is divided into ten equally sized subframes. Each sub-frame consists of two equally sized slots. Each sub-frame can be assigned for either downlink or 

uplink transmission [there are certain restrictions in the assignment as the first and sixth sub-frame of each frame 

include the downlink synchronization signals] 

Figure 5.1-1: Generic frame structure 

In addition, for coexistence with LCR-TDD, an alternative frame structure illustrated in Figure 5.1-2 is also supported 

when operating E-UTRA in TDD mode. 

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

Release 8 17 3GPP TS 36.300 V8.1.0 (2007-06)

Figure 5.1-2: alternative frame structure

5.1 Downlink Transmission Scheme 

5.1.1 Basic transmission scheme based on OFDM 

The downlink transmission scheme is based on conventional OFDM using a cyclic prefix. The OFDM sub-carrier 

spacing is f = 15 kHz. 12 consecutive sub-carriers during one slot correspond to one downlink resource block. In the 

frequency domain, the number of resource blocks, NRB, can range from NRB-min = 6 to NRB-max = [110]. 

In addition there is also a reduced sub-carrier spacingflow = 7.5 kHz, only for MBMS-dedicated cell. 

In the case of 15 kHz sub-carrier spacing there are two cyclic-prefix lengths, corresponding to seven and six OFDM 

symbols per slot respectively. 

- Normal cyclic prefix: TCP = 160Ts (OFDM symbol #0) , TCP = 144Ts (OFDM symbol #1 to #6) 

- Extended cyclic prefix: TCP-e = 512Ts (OFDM symbol #0 to OFDM symbol #5) 

where Ts = 1/ (2048  f) 

In case of 7.5 kHz sub-carrier spacing, there is only a single cyclic prefix length TCP-low = 1024Ts, corresponding to 3 

OFDM symbols per slot. 

In case of FDD, operation with half duplex from UE point of view is supported. 

For operation in unpaired spectrum with generic frame structure, DL/UL switching points are generated by not 

transmitting in certain symbols while idle periods, required by the Node B at UL/DL switching points are created using 

time advance mechanism. For the alternative frame structure, the cyclic prefix length, in case of 15 kHz sub-carrier 

spacing, is 

- Normal cyclic prefix: TCP = 224Ts (OFDM symbol #0 to #8) 

- Extended cyclic prefix: TCP-e = 512Ts (OFDM symbol #0 to #7) 

5.1.2 Physical-layer processing 

The downlink physical-layer processing of transport channels consists of the following steps: 

- CRC insertion: 24 bit CRC is the baseline for PDSCH; 

- Channel coding: Turbo coding based on QPP inner interleaving with trellis termination; 

- Physical-layer hybrid-ARQ processing; 

- Channel interleaving; 

- Scrambling: transport-channel specific scrambling on DL-SCH, BCH, and PCH. Common MCH scrambling for 

all cells involved in a specific MBSFN transmission; 

- Modulation: QPSK, 16QAM, and 64QAM; 

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

Release 8 18 3GPP TS 36.300 V8.1.0 (2007-06)

- Layer mapping and pre-coding; 

- Mapping to assigned resources and antenna ports. 

5.1.3 Physical downlink control channel 

The downlink control signalling is located in the first n OFDM symbols where n  3 and consists of: 

- Transport format, resource allocation, and hybrid-ARQ information related to DL-SCH, and PCH; 

- Uplink scheduling grant; 

- ACK/NAK in response to uplink transmission. 

Transmission of control signalling from these groups is mutually independent, e.g., ACK/NAK can be transmitted to a 

UE regardless of whether the same UE is receiving scheduling information or not. 

Multiple physical downlink control channels are supported and a UE monitors a set of control channels. 

Control channels are formed by aggregation of control channel elements, each control channel element consisting of a 

set of resource elements. Different code rates for the control channels are realized by aggregating different numbers of 

control channel elements. 

QPSK modulation is used for all control channels. 

Each separate control channel has its own set of x-RNTI. 

There is an implicit relation between the uplink resources used for dynamically scheduled data transmission, or the DL 

control channel used for assignment, and the downlink ACK/NAK resource used for feedback 

5.1.4 Downlink Reference signal 

The downlink reference signals consist of known reference symbols inserted in the first and third last OFDM symbol of 

each slot. There is one reference signal transmitted per downlink antenna port. The number of downlink antenna ports 

equals 1, 2, or 4. The two-dimensional reference signal sequence is generated as the symbol-by-symbol product of a 

two-dimensional orthogonal sequence and a two-dimensional pseudo-random sequence. There are 3 different twodimensional orthogonal sequences and 170 different two-dimensional pseudo-random sequences. Each cell identity 

corresponds to a unique combination of one orthogonal sequence and one pseudo-random sequence, thus allowing for 

510 unique cell identities 170 cell identity groups with 3 cell identities in each group). 

Frequency hopping can be applied to the downlink reference signals. The frequency hopping pattern has a period of one 

frame (10 ms). Each frequency hopping pattern corresponds to one cell identity group. 

The downlink MBSFN reference signals consist of known reference symbols inserted every other sub-carrier in the 3rd, 

7th and 11th OFDM symbol of sub-frame in case of 15kHz sub-carrier spacing and extended cyclic prefix 

5.1.5 Downlink multi-antenna transmission 

Multi-antenna transmission with 2 and 4 transmit antennas is supported. The maximum number of codeword is two 

irrespective to the number of antennas with fixed mapping between code words to layers. 

Spatial division multiplexing (SDM) of multiple modulation symbol streams to a single UE using the same timefrequency (-code) resource, also referred to as Single-User MIMO (SU-MIMO) is supported. When a MIMO channel is 

solely assigned to a single UE, it is known as SU-MIMO. Spatial division multiplexing of modulation symbol streams 

to different UEs using the same time-frequency resource, also referred to as MU-MIMO, is also supported. There is 

semi-static switching between SU-MIMO and MU-MIMO per UE. 

In addition, the following techniques are supported: 

- Code-book-based pre-coding with a single pre-coding feedback per full system bandwidth when the system 

bandwidth (or subset of resource blocks) is smaller or equal to12RB and per 5 adjacent resource blocks or the 

full system bandwidth (or subset of resource blocks) when the system bandwidth is larger than 12RB. 

- Rank adaptation with single rank feedback referring to full system bandwidth. Node B can override rank report. 

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

Release 8 19 3GPP TS 36.300 V8.1.0 (2007-06)

5.1.6 MBSFN transmission 

MBSFN is supported for the MCH transport channel. Multiplexing of transport channels using MBSFN and nonMBSFN transmission is done on a per-sub-frame basis. Additional reference symbols, transmitted using MBSFN are 

transmitted within MBSFN subframes. 

5.1.7 Physical layer procedure 

5.1.7.1 Link adaptation 

Link adaptation (AMC: adaptive modulation and coding) with various modulation schemes and channel coding rates is 

applied to the shared data channel. The same coding and modulation is applied to all groups of resource blocks 

belonging to the same L2 PDU scheduled to one user within one TTI and within a single stream. 

5.1.7.2 Power Control 

Downlink power control can be used. 

5.1.7.3 Cell search 

Cell search is the procedure by which a UE acquires time and frequency synchronization with a cell and detects the Cell 

ID of that cell. E-UTRA cell search supports a scalable overall transmission bandwidth corresponding to 72 sub-carriers 

and upwards. 

E-UTRA cell search is based on following signals transmitted in the downlink: the primary and secondary 

synchronization signals, the downlink reference signals. 

The primary and secondary synchronization signals are transmitted over the centre 72 sub-carriers in the first and sixth 

subframe of each frame. 

Neighbour-cell search is based on the same downlink signals as initial cell search.

5.1.8 Physical layer measurements definition 

The physical layer measurements to support mobility are classified as: 

- within E-UTRAN (intra-frequency, inter-frequency); 

- between E-UTRAN and GERAN/UTRAN (inter-RAT). 

For measurements within E-UTRAN at least two basic UE measurement quantities shall be supported: 

- Reference symbol received power (RSRP); 

- E-UTRA carrier received signal strength indicator (RSSI). 

5.2 Uplink Transmission Scheme 

5.2.1 Basic transmission scheme 

For both FDD and TDD, the uplink transmission scheme is based on single-carrier FDMA, more specifically DFTSOFDM. 

Figure 5.2.1: Transmitter scheme of SC-FDMA

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

Release 8 20 3GPP TS 36.300 V8.1.0 (2007-06)

The uplink sub-carrier spacing f = 15 kHz. The sub-carriers are grouped into sets of 12 consecutive sub-carriers, 

corresponding to the uplink resource blocks. 12 consecutive sub-carriers during one slot correspond to one uplink 

resource block. In the frequency domain, the number of resource blocks, NRB, can range from NRB-min = 6 to NRB-max = 

[110]. 

There are two cyclic-prefix lengths defined: Normal cyclic prefix and extended cyclic prefix corresponding to seven 

and six SC-FDMA symbol per slot respectively. 

- Normal cyclic prefix: TCP = 160Ts (SC-FDMA symbol #0) , TCP = 144Ts (SC-FDMA symbol #1 to #6) 

- Extended cyclic prefix: TCP-e = 512Ts (SC-FDMA symbol #0 to SC-FDMA symbol #5) 

Correspondingly, for the alternative frame structure, the cyclic prefix length is listed in table 5.2 

Table 5.2: Cyclic prefix length for alternative frame structure 

l

Normal cyclic prefix Extended cyclic prefix 

300 UL NBW  UL 300  NBW 300 UL NBW  UL 300  NBW

NCP,l Nd NCP,l Nd NCP,l Nd NCP,l Nd

0 320 2048 224 2048 560 2048 472 2048 

1 

192 

1024 

204 

1024 

423 

1024 

456 

1024 

2 

2048 2048 2048 2048 

3 

4 

5 

6 

7 1024 1024 

8 1024 1024 2048 2048 

9 2048 2048 

5.2.2 Physical-layer processing 

The uplink physical layer processing of transport channels consists of the following steps: 

- CRC insertion: 24 bit CRC is the baseline for PUSCH; 

- Channel coding: turbo coding based on QPP inner interleaving with trellis termination; 

- Physical-layer hybrid-ARQ processing; 

- Scrambling: UE-specific scrambling; 

- Modulation: QPSK, 16QAM, and 64QAM (optional in UE); 

- Mapping to assigned resources [and antennas]. 

5.2.3 Physical uplink control channel 

The PUCCH shall be mapped to a control channel resource in the uplink. A control channel resource is defined by a 

code and two resource blocks, consecutive in time, with hopping at the slot boundary. 

Depending on presence or absence of uplink timing synchronization, the uplink physical control signalling can differ. 

In the case of time synchronization being present, the outband control signalling consists of: 

- CQI; 

- ACK/NAK; 

- Scheduling request. 

The CQI informs the scheduler about the current channel conditions as seen by the UE. If MIMO transmission is used, 

the CQI includes necessary MIMO-related feedback. 

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

Release 8 21 3GPP TS 36.300 V8.1.0 (2007-06)

The HARQ feedback in response to downlink data transmission consists of a single ACK/NAK bit per HARQ process. 

5.2.4 Uplink Reference signal 

Uplink reference signals [for channel estimation for coherent demodulation] are transmitted in the 4-th block of the slot 

[assumed normal CP]. The uplink reference signals sequence length equals the size (number of sub-carriers) of the 

assigned resource. 

The uplink reference signals are based on [prime-length] Zadoff-chu sequences that are either truncated or cyclically 

extended to the desired length 

Multiple reference signals can be created: 

- Based on different Zadoff-Chu sequence from the same set of Zadoff-Chu sequences; 

- Different shifts of the same sequence. 

5.2.5 Random access preamble 

The physical layer random access burst consists of a cyclic prefix, a preamble, and a guard time during which nothing is 

transmitted. 

The random access preambles are generated from Zadoff-Chu sequences with zero correlation zone, ZC-ZCZ, 

generated from one or several root Zadoff-Chu sequences. 

5.2.6 Uplink multi-antenna transmission 

The baseline antenna configuration for uplink MIMO is MU-MIMO. To allow for MU-MIMO reception at the Node B, 

allocation of the same time and frequency resource to several UEs, each of which transmitting on a single antenna, is 

supported. 

Closed loop type adaptive antenna selection transmit diversity shall be supported for FDD (optional in UE). 

5.2.7 Physical channel procedure 

5.2.7.1 Link adaptation 

Uplink link adaptation is used in order to guarantee the required minimum transmission performance of each UE such 

as the user data rate, packet error rate, and latency, while maximizing the system throughput. 

Three types of link adaptation are performed according to the channel conditions, the UE capability such as the 

maximum transmission power and maximum transmission bandwidth etc., and the required QoS such as the data rate, 

latency, and packet error rate etc. Three link adaptation methods are as follows. 

- Adaptive transmission bandwidth; 

- Transmission power control; 

- Adaptive modulation and channel coding rate. 

5.2.7.2 Uplink Power control 

Intra-cell power control: the power spectral density of the uplink transmissions can be influenced by the eNB.

5.2.7.3 Uplink timing control 

The timing advance is derived from the UL received timing and sent by the eNB to the UE which the UE uses to 

advance/delay its timings of transmissions to the eNB so as to compensate for propagation delay and thus time align the 

transmissions from different UEs with the receiver window of the eNB. 

The timing advance command is on a per need basis with a granularity in the step size of 0.52 s (16Ts). 

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

Release 8 22 3GPP TS 36.300 V8.1.0 (2007-06)

5.3 Transport Channels 

The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services 

are described by how and with what characteristics data are transferred over the radio interface. An adequate term for 

this is “Transport Channel”. 

NOTE: This should be clearly separated from the classification of what is transported, which relates to the 

concept of logical channels at MAC sublayer. 

Downlink transport channel types are: 

1. Broadcast Channel (BCH) characterised by: 

- fixed, pre-defined transport format; 

- requirement to be broadcast in the entire coverage area of the cell. 

2. Downlink Shared Channel (DL-SCH) characterised by: 

- support for HARQ; 

- support for dynamic link adaptation by varying the modulation, coding and transmit power; 

- possibility to be broadcast in the entire cell; 

- possibility to use beamforming; 

- support for both dynamic and semi-static resource allocation; 

- support for UE discontinuous reception (DRX) to enable UE power saving; 

- support for MBMS transmission (FFS). 

NOTE: the possibility to use slow power control depends on the physical layer. 

3. Paging Channel (PCH) characterised by: 

- support for UE discontinuous reception (DRX) to enable UE power saving (DRX cycle is indicated by the 

network to the UE); 

- requirement to be broadcast in the entire coverage area of the cell; 

- mapped to physical resources which can be used dynamically also for traffic/other control channels. 

4. Multicast Channel (MCH) characterised by: 

- requirement to be broadcast in the entire coverage area of the cell; 

- support for SFN combining of MBMS transmission on multiple cells; 

- support for semi-static resource allocation e.g. with a time frame of a long cyclic prefix. 

Uplink transport channel types are: 

1. Uplink Shared Channel (UL-SCH) characterised by: 

- possibility to use beamforming; (likely no impact on specifications) 

- support for dynamic link adaptation by varying the transmit power and potentially modulation and coding; 

- support for HARQ; 

- support for both dynamic and semi-static resource allocation. 

NOTE: the possibility to use uplink synchronisation and timing advance depend on the physical layer. 

2. Random Access Channel(s) (RACH) characterised by: 

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

Release 8 23 3GPP TS 36.300 V8.1.0 (2007-06)

- limited control information; 

- collision risk; 

NOTE: the possibility to use open loop power control depends on the physical layer solution. 

5.3.1 Mapping between transport channels and physical channels 

The figures below depict the mapping between transport and physical channels (in grey the items for FFS): 

Figure 5.3.1-1: Mapping between downlink transport channels and downlink physical channels 

Figure 5.3.1-2: Mapping between uplink transport channels and uplink physical channels 

5.4 E-UTRA physical layer model 

The E-UTRA physical-layer model captures those characteristics of the E-UTRA physical-layer that are relevant from 

the point-of-view of higher layers. More specifically, the physical-layer model captures: 

- The structure of higher-layer data being passed down to or up from the physical layer; 

- The means by which higher layers can configure the physical layer; 

- The different indications (error indications, channel-quality indications, etc.) that are provided by the physical 

layer to higher layers; 

- Other (non-transport-channel-based) higher-layer peer-to-peer signalling supported by the physical layer. 

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

Release 8 24 3GPP TS 36.300 V8.1.0 (2007-06)

5.4.1 Physical-layer model of E-UTRA transport channels 

5.4.1.1 Downlink-Shared Channel 

The DL-SCH physical-layer model is described based on the corresponding DL-SCH physical-layer-processing chain, 

see Figure 5.4.1.1. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 

configurable by higher layers, are highlighted in blue on the figure. 

- Higher-layer data passed to/from the physical layer

- N (at least up to two) transport blocks of dynamic size delivered to the physical layer once every TTI. 

- CRC and transport-block-error indication

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 

resource assignment; 

- Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 

Hybrid-ARQ process controls what redundancy version is to be used for the physical layer transmission for 

each TTI. 

- Interleaving

- No control of interleaving by higher layers. 

- Data modulation

- Modulation scheme is decided by MAC Scheduler (QPSK, 16QAM and 64 QAM). 

- Mapping to resource blocks

- L2-controlled resource assignment. 

- Physical-layer processing Step 6: Multi-antenna processing

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 

number of antenna ports.

- Support for Hybrid-ARQ-related signalling

 The model of Figure 5.4.1.1 also captures: 

- Transport via physical layer of Hybrid-ARQ related information associated with the DL-SCH, to the peer 

HARQ process at the receiver side; 

- Transport via physical layer of corresponding HARQ acknowledgements to DL-SCH transmitter side. 

NOTE: The signalling of transport-format and resource-allocation is not captured in the physical-layer model. At 

the transmitter side, this information can be directly derived from the configuration of the physical layer. 

The physical layer then transports this information over the radio interface to its peer physical layer, 

presumably multiplexed in one way or another with the HARQ-related information. On the receiver side, 

this information is, in contrast to the HARQ-related information, used directly within the physical layer 

for DL-SCH demodulation, decoding etc., without passing through higher layers. 

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

Release 8 25 3GPP TS 36.300 V8.1.0 (2007-06)

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping

Coding + RM

QPSK, 16QAM, 

Data modulation 64QAM

Interleaving

HARQ

MAC scheduler

N Transport blocks

(dynamic size S1..., SN)

Node B

Redundancy for

data detection

Redundancy for

error detection

Multi-antenna

processing

Resource/power

assignment

Modulation

scheme

Redundancy

version

Antenna

mapping

HARQ info

ACK/NACK

Channel-state

information, etc.

Antenna mapping

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

HARQ

UE

HARQ info

ACK/NACK

Antenna demapping

Error

indications

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping

Coding + RM

QPSK, 16QAM, 

Data modulation 64QAM

Interleaving

HARQ

MAC scheduler

N Transport blocks

(dynamic size S1..., SN)

Node B

Redundancy for

data detection

Redundancy for

error detection

Multi-antenna

processing

Resource/power

assignment

Modulation

scheme

Redundancy

version

Antenna

mapping

HARQ info

ACK/NACK

Channel-state

information, etc.

Antenna mapping

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

HARQ

UE

HARQ info

ACK/NACK

Antenna demapping

Error

indications

Figure 5.4.1.1: DL-SCH physical-layer model 

When carrying information related to PCCH or BCCH, the L1/L2 control channel may need to be more robust (FFS). 

5.4.1.2 Broadcast Channel 

The BCH transport channel is characterized by a fixed pre-defined transport format. The TTI (repetition rate) of the 

BCH is 40ms. In case problems are discovered, e.g. w.r.t. the reading of BCH from neighbouring cells, a TTI of 20ms 

will be used. The BCH physical-layer model is described based on the corresponding BCH physical-layer-processing 

chain, see Figure 5.4.1.2: 

- Higher-layer data passed to/from the physical layer

- A single (fixed-size) transport block per TTI. 

- CRC and transport-block-error indication

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 

resource assignment; 

- No BCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 

- Interleaving

- No control of interleaving by higher layers. 

- Data modulation

- Fixed modulation scheme (QPSK), i.e. not higher-layer control. 

- Mapping to resource blocks

- Fixed pre-determined transport format and resource allocation, i.e. no higher-layer control.

- Physical-layer processing Step 6: Multi-antenna processing 

- Fixed pre-determined processing, i.e. no higher-layer control. 

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

Release 8 26 3GPP TS 36.300 V8.1.0 (2007-06)

- Support for Hybrid-ARQ-related signalling

- No Hybrid ARQ. 

CRC 

Resource mapping

Coding + RM

Data modulation QPSK only

Interleaving

Single Transport blocks

(fixed size S)

Node B

Antenna mapping

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indication

CRC 

Resource mapping

Coding + RM

Data modulation QPSK only

Interleaving

Single Transport blocks

(fixed size S)

Node B

Antenna mapping

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indication

Figure 5.4.1.2: BCH physical-layer model 

5.4.1.3 Paging Channel 

The PCH physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see 

Figure 5.4.1.3. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 

configurable by higher layers, are highlighted in blue on the figure. 

- Higher-layer data passed to/from the physical layer

- A single transport block per TTI. 

- CRC and transport-block-error indication

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 

resource assignment; 

- No PCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 

- Interleaving

- No control of interleaving by higher layers. 

- Data modulation

- Modulation scheme is decided by MAC Scheduler. 

- Mapping to resource blocks

- L2 controlled resource assignment;

- Possible support of dynamic transport format and resource allocation.

- Physical-layer processing Step 6: Multi-antenna processing 

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

Release 8 27 3GPP TS 36.300 V8.1.0 (2007-06)

- MAC Scheduler partly configures mapping from assigned resource blocks to the available number of antenna 

ports.

- Support for Hybrid-ARQ-related signalling

 No Hybrid ARQ. 

CRC 

Resource mapping

Coding + RM

Data modulation

Interleaving

MAC scheduler

Single Transport blocks

(dynamic size S)

Node B

Resource/power

assignment

Modulation

scheme

Antenna

mapping

Antenna mapping

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indication

CRC 

Resource mapping

Coding + RM

Data modulation

Interleaving

MAC scheduler

Single Transport blocks

(dynamic size S)

Node B

Resource/power

assignment

Modulation

scheme

Antenna

mapping

Antenna mapping

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indication

Figure 5.4.1.3: PCH physical-layer model 

5.4.1.4 Multicast Channel 

The MCH is characterized by the support for multi-cell reception at the UE (a.k.a. “SFN” transmission). This implies 

that only semi-static configuration of the MCH transport format and resource assignment is possible. The MCH 

physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see Figure 5.4.1.4. 

Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher 

layers, are highlighted in blue. 

- Higher-layer data passed to/from the physical layer

- N (at least up to 2) transport blocks delivered to physical layer once every TTI.

- CRC and transport-block-error indication

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 

resource assignment; 

- No MCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 

- Interleaving

- No control of interleaving by higher layers. 

- Data modulation

- Modulation scheme is decided by MAC Scheduler. 

- Mapping to resource blocks

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

Release 8 28 3GPP TS 36.300 V8.1.0 (2007-06)

- L2 controlled semi–static resource assignment.

- Physical-layer processing Step 6: Multi-antenna processing

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 

number of antenna ports.

- Support for Hybrid-ARQ-related signalling

- No Hybrid ARQ. 

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping

Coding + RM

Data modulation

Interleaving

MAC scheduler

N Transport blocks

(dynamic size S1..., SN)

Node B

Resource/power

assignment

Modulation

scheme

Antenna

mapping

Antenna mapping

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indications

Semi-static

configuration

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping

Coding + RM

Data modulation

Interleaving

MAC scheduler

N Transport blocks

(dynamic size S1..., SN)

Node B

Resource/power

assignment

Modulation

scheme

Antenna

mapping

Antenna mapping

CRC 

RB mapping

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

UE

Antenna demapping

Error

indications

Semi-static

configuration

Figure 5.4.1.4: MCH physical-layer model 

5.4.1.5 Uplink Shared Channel 

The UL-SCH physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see 

Figure 5.4.1.5. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 

configurable by higher layers, are highlighted in blue. It should be noted that, in case UL-SCH, the scheduling decision 

is at least partly made at the network side. The uplink transmission control in the UE then configures the uplink 

physical-layer processing, based on uplink transport-format and resource-assignment information received on the 

downlink. 

- Higher-layer data passed to/from the physical layer

- N (N may be limited to one) transport blocks of dynamic size delivered to the physical layer once every TTI.

- CRC and transport-block-error indication

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 

resource assignment; 

- Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 

Hybrid-ARQ process controls what redundancy version is to be used for the physical layer transmission for 

each TTI. 

- Interleaving

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

Release 8 29 3GPP TS 36.300 V8.1.0 (2007-06)

- No control of interleaving by higher layers. 

- Data modulation

- Modulation scheme is decided by MAC Scheduler (at least QPSK and 16QAM). 

- Mapping to resource blocks

- L2-controlled resource assignment.

- Physical-layer processing Step 6: Multi-antenna processing

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 

number of antenna ports.

- Support for Hybrid-ARQ-related signalling

 The model of Figure 5.4.1.5 also captures 

- Transport via physical layer of Hybrid-ARQ related information (exact info is FFS) associated with the ULSCH, to the peer HARQ process at the receiver side; 

- Transport via physical layer of corresponding HARQ acknowledgements to UL-SCH transmitter side. 

CRC 

RB mapping 

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

MAC scheduler

Node B

Resource

assignment

Modulation

scheme

Redundancy

version

Antenna

mapping

HARQ info

ACK/NACK

Antenna demapping 

CRC 

RB mapping 

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping 

Coding + RM

Data modulation 

Interleaving

HARQ

UE

HARQ info

ACK/NACK

Antenna mapping 

N Transport blocks

(dynamic size S1..., SN)

Error

indications

Resource/power

assignment

Modulation

scheme

Antenna

mapping

HARQ

Uplink transmission control

Channel-state 

information, etc.

CRC 

RB mapping 

Coding + RM

Data modulation

Interl. 

CRC 

Resource demapping

Decoding + RM

Data demodulation

Deinterleaving

MAC scheduler

Node B

Resource

assignment

Modulation

scheme

Redundancy

version

Antenna

mapping

HARQ info

ACK/NACK

Antenna demapping 

CRC 

RB mapping 

Coding + RM

Data modulation

Interl. 

CRC 

Resource mapping 

Coding + RM

Data modulation 

Interleaving

HARQ

UE

HARQ info

ACK/NACK

Antenna mapping 

N Transport blocks

(dynamic size S1..., SN)

Error

indications

Resource/power

assignment

Modulation

scheme

Antenna

mapping

HARQ

Uplink transmission control

Channel-state 

information, etc.

Figure 5.4.1.5: UL-SCH physical-layer model 

5.4.1.6 Random-access Channel 

5.4.2 Physical-layer indications 

In addition to decoded transport blocks, the physical layer also provides higher layers with different indicators. The 

indicators delivered to higher layers may originate in the corresponding physical layer on in the physical layer of the 

peer entity (transported over the air by means of L1 signalling). 

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

Release 8 30 3GPP TS 36.300 V8.1.0 (2007-06)

5.4.2.1 Error indicators 

The error indicators (see Figures 5.4.1.1-5.4.1.5) are one type of indicators. An error indicator indicates whether or not 

the physical layer has correctly decoded a received transport block 

5.4.2.2 Channel-quality indicators 

Channel-quality indicators (CQI) indicate the downlink and uplink channel quality. The channel-quality indicators are 

delivered by the eNB physical layer to the eNB MAC layer. Exactly how the channel-quality indicators are generated 

within the physical layer is a physical-layer-internal issue and may e.g. depend on the duplex scheme (FDD or TDD). 

6 Layer 2 

Layer 2 is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC) and Packet 

Data Convergence Protocol (PDCP). 

This subclause gives a high level description of the Layer 2 sub-layers in terms of services and functions. The two 

figures below depict the PDCP/RLC/MAC architecture for downlink and uplink, where: 

- Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between 

sublayers. The SAP between the physical layer and the MAC sublayer provides the transport channels. The 

SAPs between the MAC sublayer and the RLC sublayer provide the logical channels. 

- The multiplexing of several logical channels (i.e. radio bearers) on the same transport channel (i.e. transport 

block) is performed by the MAC sublayer; 

- In both uplink and downlink, only one transport block is generated per TTI in the non-MIMO case. 

 

Figure 6-1: Layer 2 Structure for DL 

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

Release 8 31 3GPP TS 36.300 V8.1.0 (2007-06)

Multiplexing

...

HARQ

Scheduling / Priority Handling

Transport Channels

MAC

RLC

PDCP

Segm.

ARQ

Segm.

ARQ

Logical Channels

ROHC ROHC

Radio Bearers

Securtiy Security

 

Figure 6-2: Layer 2 Structure for UL 

6.1 MAC Sublayer 

This subclause provides an overview on services and functions provided by the MAC sublayer. 

6.1.1 Services and Functions 

The main services and functions of the MAC sublayer include: 

- Mapping between logical channels and transport channels; 

- Multiplexing/demultiplexing of RLC PDUs belonging to one or different radio bearers into/from transport blocks 

(TB) delivered to/from the physical layer on transport channels; 

- Traffic volume measurement reporting; 

- Error correction through HARQ; 

- Priority handling between logical channels of one UE; 

- Priority handling between UEs by means of dynamic scheduling; 

- Transport format selection; 

- Padding. 

NOTE: How the multiplexing relates to the QoS of the multiplexed logical channels is FFS. 

6.1.2 Logical Channels 

Different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of 

information is transferred. 

A general classification of logical channels is into two groups: 

- Control Channels (for the transfer of control plane information); 

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

Release 8 32 3GPP TS 36.300 V8.1.0 (2007-06)

- Traffic Channels (for the transfer of user plane information). 

There is one MAC entity per cell. MAC generally consists of several function blocks (transmission scheduling functions, 

per UE functions, MBMS functions, MAC control functions, transport block generation...). Transparent Mode is only 

applied to BCCH, CCCH and PCCH. 

6.1.2.1 Control Channels 

Control channels are used for transfer of control plane information only. The control channels offered by MAC are: 

- Broadcast Control Channel (BCCH) 

 A downlink channel for broadcasting system control information. 

- Paging Control Channel (PCCH) 

 A downlink channel that transfers paging information. This channel is used when the network does not know the 

location cell of the UE. 

- Common Control Channel (CCCH) 

 Uplink channel for transmitting control information between UEs and network. This channel is used by the UEs 

having no RRC connection with the network. FFS if CCCH needed in downlink as well. 

- Multicast Control Channel (MCCH) 

 A point-to-multipoint downlink channel used for transmitting MBMS control information from the network to 

the UE, for one or several MTCHs. This channel is only used by UEs that receive MBMS. 

NOTE: It is FFS how MBMS scheduling is transmitted by either L2/3 signalling on MCCH or L1 signalling. 

- Dedicated Control Channel (DCCH) 

 A point-to-point bi-directional channel that transmits dedicated control information between a UE and the 

network. Used by UEs having an RRC connection. 

6.1.2.2 Traffic Channels 

Traffic channels are used for the transfer of user plane information only. The traffic channels offered by MAC are: 

- Dedicated Traffic Channel (DTCH) 

 A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user 

information. A DTCH can exist in both uplink and downlink. 

- Multicast Traffic Channel (MTCH) 

 A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE. This channel is 

only used by UEs that receive MBMS. 

6.1.3 Mapping between logical channels and transport channels 

6.1.3.1 Mapping in Uplink 

The figure below depicts the mapping between uplink logical channels and uplink transport channels: 

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

Release 8 33 3GPP TS 36.300 V8.1.0 (2007-06)

CCCH DCCH DTCH

RACH UL-SCH

Uplink

Logical channels

Uplink

Transport channels

 

Figure 6.1.3.1: Mapping between uplink logical channels and uplink transport channels 

In Uplink, the following connections between logical channels and transport channels exist: 

- CCCH can be mapped to UL-SCH; 

- DCCH can be mapped to UL- SCH; 

- DTCH can be mapped to UL-SCH. 

6.1.3.2 Mapping in Downlink 

The figure below depicts the mapping between downlink logical channels and downlink transport channels (in grey the 

items for FFS): 

Figure 6.1.3.2: Mapping between downlink logical channels and downlink transport channels 

In Downlink, the following connections between logical channels and transport channels exist: 

- BCCH can be mapped to BCH; 

- BCCH can be mapped to DL-SCH; 

- PCCH can be mapped to PCH; 

- CCCH can be mapped to DL-SCH: FFS if CCCH exists; 

- DCCH can be mapped to DL-SCH; 

- DTCH can be mapped to DL-SCH; 

- MTCH can be mapped to DL-SCH; 

- MTCH can be mapped to MCH; 

- MCCH can be mapped to DL-SCH; 

- MCCH can be mapped to MCH. 

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

Release 8 34 3GPP TS 36.300 V8.1.0 (2007-06)

6.2 RLC Sublayer 

This subclause provides an overview on services, functions and PDU structure provided by the RLC sublayer. Note 

that: 

- The reliability of RLC is configurable: some radio bearers may tolerate rare losses (e.g. TCP traffic); 

- Radio Bearers are not characterized by a fixed sized data unit (e.g. a fixed sized RLC PDU). 

6.2.1 Services and Functions 

The main services and functions of the RLC sublayer include: 

- Transfer of upper layer PDUs supporting AM or UM; 

- TM data transfer; 

- Error Correction through ARQ (CRC check provided by the physical layer, in other words no CRC needed at 

RLC level); 

- Segmentation according to the size of the TB: only if an RLC SDU does not fit entirely into the TB then the 

RLC SDU is segmented into variable sized RLC PDUs, which do not include any padding; 

- Re-segmentation of PDUs that need to be retransmitted: if a retransmitted PDU does not fit entirely into the new 

TB used for retransmission then the RLC PDU is re-segmented; 

- The number of re-segmentation is not limited; 

- Concatenation of SDUs for the same radio bearer; 

- In-sequence delivery of upper layer PDUs except at HO in the uplink; 

- Duplicate Detection; 

- Protocol error detection and recovery; 

- Flow Control between eNB and UE (FFS); 

- SDU discard; 

- Reset. 

6.2.2 PDU Structure 

Figure 6.2.2 below depicts the RLC PDU structure where: 

- The PDU sequence number carried by the RLC header is independent of the SDU sequence number (i.e. PDCP 

sequence number); 

- A red dotted line indicates the occurrence of segmentation; 

- Because segmentation only occurs when needed and concatenation is done in sequence, the content of an RLC 

PDU can generally be described by the following relations: 

- {0; 1} last segment of SDUi + [0; n] complete SDUs + {0; 1} first segment of SDUi+n+1 ; or 

- 1 segment of SDUi . 

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

Release 8 35 3GPP TS 36.300 V8.1.0 (2007-06)

Figure 6.2.2: RLC PDU Structure 

6.3 PDCP Sublayer 

This subclause provides an overview on services, functions and PDU structure provided by the PDCP sublayer. 

6.3.1 Services and Functions 

The main services and functions of the PDCP sublayer include: 

- Header compression and decompression: ROHC only; 

- Transfer of user data: transmission of user data means that PDCP receives PDCP SDU from the NAS and 

forwards it to the RLC layer and vice versa; 

- In-sequence delivery of upper layer PDUs at HO; 

- Duplicate detection of lower layer SDUs; 

- Ciphering of user plane data and control plane data; 

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

6.3.2 PDU Structure 

Figure 6.3.2 below depicts the PDCP PDU structure where: 

- PDCP PDU and PDCP header are octet-aligned; 

- PDCP header can be either 1 or 2 bytes long. 

Figure 6.3.2: PDCP PDU Structure 

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

Release 8 36 3GPP TS 36.300 V8.1.0 (2007-06)

6.4 Data flows through Layer 2 

7 RRC 

This subclause provides an overview on services and functions provided by the RRC sublayer. 

7.1 Services and Functions 

The main services and functions of the RRC sublayer include: 

- Broadcast of System Information related to the non-access stratum (NAS); 

- Broadcast of System Information related to the access stratum (AS); 

- Paging; 

- Establishment, maintenance and release of an RRC connection between the UE and E-UTRAN including: 

- Allocation of temporary identifiers between UE and E-UTRAN; 

- Configuration of signalling radio bearer(s) for RRC connection: 

- Low priority SRB and high priority SRB. 

- Security functions including: 

- Integrity protection for RRC messages. 

- Establishment, configuration, maintenance and release of point to point Radio Bearers; 

- Mobility functions including: 

- UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility; 

- Inter-cell handover; 

- UE cell selection and reselection and control of cell selection and reselection; 

- Context transfer between eNBs. 

- Notification for MBMS services (FFS); 

- Establishment, configuration, maintenance and release of Radio Bearers for MBMS services (FFS); 

- QoS management functions; 

- UE measurement reporting and control of the reporting; 

- MBMS control (FFS); 

- NAS direct message transfer to/from NAS from/to UE. 

7.2 RRC protocol states & state transitions 

RRC uses the following states: 

- RRC_IDLE: 

- UE specific DRX configured by NAS; 

- Broadcast of system information; 

- Paging; 

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

Release 8 37 3GPP TS 36.300 V8.1.0 (2007-06)

- Cell re-selection mobility; 

- The UE shall have been allocated an id which uniquely identifies the UE in a tracking area; 

- No RRC context stored in the eNB. 

- RRC_CONNECTED: 

- UE has an E-UTRAN-RRC connection; 

- UE has context in E-UTRAN; 

- E-UTRAN knows the cell which the UE belongs to; 

- Network can transmit and/or receive data to/from UE; 

- Network controlled mobility (handover); 

- Neighbour cell measurements; 

- At PDCP/RLC/MAC level: 

- UE can transmit and/or receive data to/from network; 

- UE monitors control signalling channel for shared data channel to see if any transmission over the shared 

data channel has been allocated to the UE; 

- UE also reports channel quality information and feedback information to eNB; 

- DRX/DTX period can be configured according to UE activity level for UE power saving and efficient 

resource utilization. This is under control of the eNB. 

7.3 Transport of NAS messages 

In E-UTRAN, NAS messages are either concatenated with RRC messages or carried in RRC without concatenation. 

Initial Direct Transfer is concatenated with RRC connection request if the transport block size allows it (FFS). Other 

NAS messages maybe concatenated with RRC messages i.e. for synchronised NAS/RRC procedure. 

NOTE: NAS messages are integrity protected by RRC and ciphered by PDCP, in addition to the integrity 

protection and ciphering performed by NAS. 

7.4 System Information 

Scheduling information (indicating starting times) is provided for a group of system information blocks (SIBs) that have 

the same scheduling requirements (i.e. periodicity). Such a group of SIBs is referred to as a Scheduling Unit (SU). It is 

expected that typically 3 or 4 SUs will be used. The mapping of SIBs on to SUs may be configurable or fixed in the 

specification (FFS). 

The following system information is carried on the BCH: 

- Physical layer parameters: 

- Downlink system bandwidth [4 bits]; 

- Number of transmit antennas [1..2 bits]; 

- Reference-Signal transmit power [0..6 bits]; 

- System Frame Number (SFN [10 bits], unless provided otherwise); 

- Scheduling information of the most frequently repeated Scheduling Unit (SU-1) (FFS) [1 bit]; 

- Cell re-selection and handover related parameters (FFS): 

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

Release 8 38 3GPP TS 36.300 V8.1.0 (2007-06)

- Offset [6 bits]. 

- Value tag(s) (FFS). 

The system information carried on BCH is contained in a System Information Block called the Master Information 

Block (MIB). 

All system information other than contained in the MIB is carried on DL-SCH. The following system information is 

carried within the most frequently repeated Scheduling Unit (SU-1): 

- One or more PLMN identities; 

- Tracking Area Code; 

- Cell identity; 

- Cell barring status; 

- Scheduling information i.e. the periodicity of the other Scheduling Units (other than SU-1); 

- SIB mapping information i.e. indication in which SU the SIB is included (FFS). 

The scheduling information, as contained within SU-1, is carried in a System Information Block called the Scheduling 

Block (SB). Besides this SB, SU-1 includes one or more other SIBs. SU-1 should include all access restriction related 

parameters. SU-1 is carried on the DL-SCH and uses a fixed schedule with a periodicity of 80 ms. 

It is FFS whether the SB includes a value tag for each SU, whether a common value tag is used. The common value tag 

could either be carried in the MIB or in the SB. 

An SU may be segmented, in which case segments are scheduled in subsequent consequtive subframes. SU-1 is 

scheduled in the subframe following the one carrying BCH (FFS for TDD). It is FFS if further SUs are scheduled in 

subsequent consequtive subframes. The eNB may schedule DL-SCH transmissions concerning logical channels other 

than BCCH in the same subframe as used for BCCH. The minimum UE capability restricts the BCCH mapped to DLSCH e.g. regarding the maximum rate. It is FFS if the eNB may schedule more than one SU in a subframe. 

System information may also be provided to the UE by means of dedicated signalling e.g. upon handover. 

7.5 RRC Procedures 

8 E-UTRAN identities 

8.1 E-UTRAN related UE identities 

The following E-UTRAN related UE identities are used: 

a) C-RNTI: 

- The C-RNTI provides a unique UE identification at the cell level identifying RRC Connection; 

- It is assumed that this identity is used for scheduling unless the cost would turn out to be too high and the 

introduction of a separate MAC identity would be required. 

b) Random value for contention resolution: 

- During some transient states, the UE is temporarily identified with a random value for contention resolution 

purposes. 

8.2 Network entity related Identities 

The following identities are used in E-UTRAN for identifying a specific network entity: 

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

Release 8 39 3GPP TS 36.300 V8.1.0 (2007-06)

a) MME identity: 

- It is agreed that a UE in LTE_IDLE establishing an RRC connection has to provide a unique identification of 

its current MME to the eNB when the connection establishment is initially related to NAS signalling, in order 

for the eNB to fetch the UE context from the MME; 

- It is FFS whether this MME identity is also provided when the RRC connection is initially intended for user 

plane traffic; 

- It is FFS whether this MME identity is provided by the UE to the eNB as a separate identity, or whether this 

MME identity is included in the TMSI for MME. 

b) eNB identity or cell identity (FFS): 

- The signalling sequence to be followed in case a UE in LTE_ACTIVE accesses a cell in which no UE 

context has been established yet (kind of “cell update”) is currently not agreed. Identified options are: 

1) In order to obtain the UE context/data from the old eNB, the new eNB directly contacts the old eNB 

without consulting the MME; 

2) In order to obtain the UE context/data from the old eNB, the new eNB consults the MME to obtain the 

identity of the old eNB; 

3) In order to obtain a UE context, the new eNB contacts the MME. 

- If it is required for the new eNB to be able to contact the old eNB without involving the MME (case 1 

above), the UE has to provide a network entity related identification that enables the new eNB to contact the 

old eNB, and that enables the old eNB to uniquely identify the UE for retrieving the correct UE context. For 

this purpose either an eNB identity or cell identity could be used. 

c) Tracking Area identity (FFS): 

- Unique identification of a Tracking Area in a PLMN. 

The following identities are broadcast in every E-UTRAN cell: 

a) Cell identity: 

- Uniquely identifying the cell in the area (size of area is FFS). 

b) Tracking Area identity: 

- Tracking Area this cell belongs to. 

c) One or more PLMNs: 

- PLMN (s) for which this cell is providing radio access. 

9 ARQ and HARQ 

E-UTRAN provides ARQ and HARQ functionalities. The ARQ functionality provides error correction by 

retransmissions in acknowledged mode at Layer 2. The HARQ functionality ensures delivery between peer entities at 

Layer 1. 

9.1 HARQ principles 

The HARQ within the MAC sublayer has the following characteristics: 

- N-process Stop-And-Wait HARQ is used; 

- The HARQ is based on ACK/NACKs; 

- In the downlink: 

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

Release 8 40 3GPP TS 36.300 V8.1.0 (2007-06)

- Asynchronous retransmissions with adaptive transmission parameters are supported; 

- Additional optimisations (e.g. less adaptive/synchronous) are FFS. 

- In the uplink: 

- HARQ is based on synchronous retransmissions; 

- Whether resource allocation and modulation and coding scheme can be adapted for retransmissions is FFS. 

- The HARQ transmits and retransmits TBs; 

9.2 ARQ principles 

The ARQ within the RLC sublayer has the following characteristics: 

- ARQ retransmits RLC PDUs or RLC PDU segments; 

- ARQ retransmissions are based on: 

- RLC status reports; 

- HARQ/ARQ interactions (see subclause 9.3). 

- Polling for RLC status report is used when needed by RLC; 

- Status reports can be triggered by upper layers; 

- Means to discard a SDU not yet transmitted or under transmission should be supported; 

- Means to reset and/or re-establish RLC should be supported. 

9.3 HARQ/ARQ interactions 

In HARQ assisted ARQ operation, ARQ uses knowledge obtained from the HARQ about the transmission/reception 

status of a TB e.g.: 

- If the HARQ transmitter detects a failed delivery of a TB due to e.g. maximum retransmission limit is reached 

the relevant transmitting ARQ entities are notified and potential retransmissions and re-segmentation can be 

initiated; 

- If the HARQ receiver is able to detect a NACK to ACK error it is FFS if the relevant transmitting ARQ entities 

are notified via explicit signalling; 

- If the HARQ receiver is able to detect TB transmission failure it is FFS if the receiving ARQ entities are notified. 

10 Mobility 

E-UTRAN mobility in LTE_IDLE and LTE_ACTIVE should provide means for load balancing. 

10.1 Intra E-UTRAN 

In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers are performed and various 

DRX/DTX cycles are supported. 

In E-UTRAN RRC_IDLE state, cell reselections are performed and DRX is supported. 

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

Release 8 41 3GPP TS 36.300 V8.1.0 (2007-06)

10.1.1 Mobility Management in LTE_IDLE 

10.1.1.1 Cell selection 

The principles of PLMN selection in E-UTRA are based on the 3GPP PLMN selection principles. Cell selection is 

required on transition from LTE_DETACHED to LTE_IDLE or LTE_ACTIVE. 

Cell selection: 

- The UE NAS identifies a selected PLMN and equivalent PLMNs; 

- The UE searches the E-UTRA frequency bands and for each carrier frequency identifies the strongest cell. It 

reads cell system information broadcast to identify its PLMN(s): 

- Details for the cell search are FFS; 

- The UE may search each carrier in turn (“initial cell selection”) or make use of stored information to shorten 

the search (“stored information cell selection”). 

- The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an 

acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and 

commence the cell reselection procedure: 

- A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN 

is the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not 

part of a tracking area which is in the list of “forbidden tracking areas for roaming”; 

- An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell 

is not barred; 

- The measurements made and the cell selection criteria to be applied are FFS. 

Transition to RRC_IDLE: 

 On transition from RRC_CONNECTED to RRC_IDLE, a UE should camp on the last cell for which it was in 

RRC_CONNECTED or a cell/any cell of set of cells or frequency be assigned by RRC in the state transition 

message. 

Recovery from out of coverage: 

 The UE should attempt to find a suitable cell in the manner described for stored information or initial cell 

selection above. If no suitable cell is found on any frequency or RAT the UE should attempt to find an 

acceptable cell. 

10.1.1.2 Cell reselection 

UE in RRC_IDLE performs cell reselection. The principles of the procedure are the following: 

- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process: 

- There is no need to indicate neighbouring cell in the serving cell system information to enable the UE to 

search and measure a cell i.e. E-UTRAN relies on the UE to detect the neighbouring cells; 

- It is FFS if there is a need to indicate specific intra-frequency neighbouring cells to speed up their detection; 

- For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be 

indicated. 

- The attributes to be measured for E-UTRAN cells are FFS; 

- Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria. The 

criteria and rules relating to which measurements may be omitted are FFS; 

- Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which 

involves measurements of the serving and neighbour cells. Details for cell reselection criteria are FFS; 

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

Release 8 42 3GPP TS 36.300 V8.1.0 (2007-06)

- It should be possible to use cell reselection parameters for specific intra-frequency neighbouring cells. The 

BCH of the neighbouring cell may include parameters that are often cell specific e.g. an offset (FFS). The 

neighbouring cell information provided by the serving cell includes parameters that are rarely cell specific or 

for which there is a need to indicate values for a specific serving- neighbouring cell pair. Consequently, the 

UE may need to read the BCH of detected neighbouring cells (FFS), possibly only for suitable cell 

reselection candidates.; 

- For inter-frequency neighbouring cells, there is no need to indicate cell-specific cell reselection parameters 

i.e. these parameters are common to all neighbouring cells on a frequency; 

- It should be possible to prevent the UE from reselecting to specific detected neighbouring cells. The details 

of the mechanism are FFS; 

- Cell reselection parameters are applicable for all UEs in a cell, but it is possible to configure specific reselection 

parameters per UE group or per UE. 

Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for 

cells “reserved for operator use”) applicable for mobiles in RRC_IDLE mode. 

10.1.1.3 Handling in eNB 

10.1.1.4 Handling above eNB 

10.1.1.5 Mobility Management Entity (MME) 

10.1.2 Mobility Management in LTE_ACTIVE 

The Intra-E-UTRAN-Access Mobility Support for UEs in LTE_ACTIVE handles all necessary steps for 

relocation/handover procedures, like processes that precedes the final HO decision on the source network side (control 

and evaluation of UE and eNB measurements taking into account certain UE specific area restrictions), preparation of 

resources on the target network side, commanding the UE to the new radio resources and finally releasing resources on 

the (old) source network side. It contains mechanisms to transfer context data between evolved nodes, and to update 

node relations on C-plane and U-plane. 

In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers are performed and various 

DRX/DTX cycles are supported: 

The UE makes measurements of attributes of the serving and neighbour cells to enable the process: 

- There is no need to indicate neighbouring cell to enable the UE to search and measure a cell i.e. E-UTRAN relies 

on the UE to detect the neighbouring cells; 

- It is FFS if there is a need to indicate specific intra-frequency neighbouring cells to speed up their detection; 

- For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be 

indicated (other information FFS). 

- Network signals reporting criteria for event-triggered and periodical reporting. 

- It should be possible to use measurement related parameters for specific intra-frequency neighbouring cells. The 

BCH of the neighbouring cell may include parameters that are often cell specific e.g. an offset (FFS). The 

neighbouring cell information provided by the serving cell includes parameters that are rarely cell specific or for 

which there is a need to indicate values for a specific serving- neighbouring cell pair. The parameter(s) is(are) 

common to CONNECTED and IDLE mode mobility. Consequently, the UE in RRC_CONNECTED may need 

to read the BCH of detected intra-frequency neighbouring cells (FFS). 

10.1.2.1 Handover 

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation 

signalling in E-UTRAN. 

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

Release 8 43 3GPP TS 36.300 V8.1.0 (2007-06)

- Part of the HO command comes from the target eNB and is transparently forwarded to the UE by the source 

eNB; 

- The QoS profiles in use by the UE (SAE bearer attributes) are sent to the target eNB by the source eNB, and it is 

FFS if also the currently used AS configuration is sent (intra-MME case); 

- Both the source ENB and UE keep some context (e.g. C-RNTI) to enable the return of the UE in case of HO 

failure; 

- UE accesses the target cell by a contention-free procedure using dedicated resources or via contention-based 

RACH if dedicated resources are not available (the use of dedicated resources for accessing the target cell in a 

contention-free manner is FFS). 

10.1.2.1.1 C-plane handling 

The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between 

the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. The 

figure below depicts the basic handover scenario where neither MME nor Serving Gateway changes: 

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

Release 8 44 3GPP TS 36.300 V8.1.0 (2007-06)

Legend

packet data packet data

 UL allocation

2. Measurement Reports

3. HO decision

4. Handover Request

5. Admission Control

6. Handover Request Ack

7. Handover Command

DL allocation

DL Data Forwarding

10. Handover Confirm

16. Release Resource

11. Handover Complete

UE Source eNB Target eNB Serving Gateway

Detach from old cell and

synchronize to new cell

Deliver buffered and in transit

packets to target eNB

Buffer packets from

Source eNB 8. Synchronisation

9. UL allocation + TA for UE

packet data

DL Data Forwarding

Flush DL buffer, continue

delivering in-transit packets

packet data

L3 signalling

L1/L2 signalling

User Data

1. Measurement Control

15. Handover Complete Ack

17. Release

Resources

Handover Completion Handover Execution Handover Preparation

MME

0. Area Restriction Provided

12. User Plane update

request

14. User Plane update

response

13. Switch DL path

Figure 10.1.2.1: Intra-MME/Serving Gateway HO 

Below is a more detailed description of the intra-MME/Serving Gateway HO procedure: 

0 The UE context within the source eNB contains information regarding roaming restrictions which where 

provided either at connection establishment or at the last TA update. 

1 The source eNB configures the UE measurement procedures according to the area restriction information. 

Measurements provided by the source eNB may assist the function controlling the UE's connection mobility. 

2 UE is triggered to send MEASUREMENT REPORT by the rules set by i.e. system information, specification 

etc. 

3 Source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off UE. 

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

Release 8 45 3GPP TS 36.300 V8.1.0 (2007-06)

4 The source eNB issues a HANDOVER REQUEST message to the target eNB passing necessary information to 

prepare the HO at the target side (UE X2 signalling context reference at source eNB, UE S1 EPC signalling 

context reference, target cell ID, RRC context, SAE bearer context). UE X2 / UE S1 signalling references enable 

the target eNB to address the source eNB and the EPC. The SAE bearer context includes necessary RNL and 

TNL addressing information. QoS profiles of the SAE bearers and possibly the AS configurations of these 

bearers are FFS. 

5 Admission Control may be performed by the target eNB dependent on the received SAE bearer QoS information 

to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB 

configures the required resources according to the received SAE bearer QoS information and reserves a C-RNTI. 

6 Target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source 

eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to 

the UE as part of the Handover Command. The container may include new C-RNTI, possibly some other 

parameters i.e. access parameters, SIBs, etc. The HANDOVER REQUEST ACKNOWLEDGE message may 

also include RNL/TNL information for the forwarding tunnels, if necessary. 

Steps 7 to 15 provide means to avoid data loss during HO and are further detailed in 10.1.2.1.2 and 10.1.2.3. 

7 The source eNB generates the HANDOVER COMMAND (RRC message) towards the UE. The HANDOVER 

COMMAND includes the transparent container, which has been received from the target eNB. The source 

eNodeB performs the necessary integrity protection and ciphering of the message. The UE receives the 

HANDOVER COMMAND with necessary parameters (i.e. new C-RNTI, possible starting time, target eNB 

SIBs etc) and is commanded by the source eNB to perform the HO. It is probable that UE needs to acknowledge 

reception of the HANDOVER COMMAND with RLC acknowledgment procedure. 

8 After expiry of starting time in HANDOVER COMMAND, UE performs synchronisation to target eNB and then 

starts acquiring UL timing advance. 

9 Network responds with UL allocation and timing advance. 

10 When the UE has successfully accessed the target cell, the UE sends the HANDOVER CONFIRM message (CRNTI) to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB 

verifies the C-RNTI sent in the HANDOVER CONFIRM message. The target eNB can now begin sending data 

to the UE. Based on further optimizations, the downlink data transmission can begin as early as after step 8 

(FFS). 

11 The target eNB sends a HANDOVER COMPLETE message to MME to inform that the UE has changed cell. 

12 The MME sends a USER PLANE UPDATE REQUEST message to the Serving Gateway. 

13 The Serving Gateway switches the downlink data path to the target side and can release any U-plane/TNL 

resources towards the source eNB. 

14 Serving Gateway sends a USER PLANE UPDATE RESPONSE message to MME. 

15 The MME confirms the HANDOVER COMPLETE message with the HANDOVER COMPLETE ACK 

message. 

16 By sending RELEASE RESOURCE the target eNB informs success of HO to source eNB and triggers the 

release of resources. The timing for the target eNB to send this message between steps 10 and 15 is FFS. 

17 Upon reception of the RELEASE RESOURCE message, the source eNB can release radio and C-plane related 

resources associated to the UE context. 

NOTE: Details on updating of roaming/area restriction information within E-UTRAN in the course of the HO 

procedure are FFS 

10.1.2.1.2 U-plane handling 

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in LTE_ACTIVE takes the 

following principles into account to avoid data loss during HO and hence to support seamless/lossless service provision: 

- During HO preparation a U-plane tunnel is established between the source eNB and the target eNB. 

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

Release 8 46 3GPP TS 36.300 V8.1.0 (2007-06)

- During HO execution, user data may be forwarded from the source eNB to the target eNB. The forwarding may 

take place in a service dependent and implementation specific way. 

- Forwarding of user data from the source to the target eNB should take place as long as packets are received at 

the source eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent 

mechanism decides that data forwarding can be stopped). 

- During HO completion: 

- The target eNB sends a HANDOVER COMPLETE message to MME to inform that the UE has gained 

access and MME sends a USER PLANE UPDATE REQUEST message to the Serving Gateway, the U-plane 

path is switched by the Serving Gateway from the source eNB to the target eNB. 

- The source eNB should continue forwarding of U-plane data as long as packets are received at the source 

eNB from the Serving Gateway or the source eNB buffer has not been emptied (an implementation 

dependent mechanism decides that data forwarding can be stopped). 

Note: Details on user plane handling are still FFS. The text above reflects the latest status of the Study Item as 

given in TR 25.912. 

10.1.2.2 Path Switch 

10.1.2.3 Data forwarding 

Upon handover, the source eNB forwards all downlink PDCP SDUs with their SN that have not been acknowledged by 

the UE to the target eNB. The decision of which SDUs to forward can be based for example on RLC status reports or 

HARQ feedback information depending on eNB implementation. The source eNB discards any remaining downlink 

RLC PDUs. The target eNB re-transmits and prioritize all downlink PDCP SDUs forwarded by the source eNB. 

Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB. 

Upon handover, the source eNB forwards uplink PDCP SDUs successfully received in-sequence to the SAE Gateway, 

forwards uplink PDCP SDUs received out-of-sequence to the target eNB and discards any remaining uplink RLC 

PDUs. The UE re-transmits the uplink PDCP SDUs that have not been successfully received by the source eNB. 

Correspondingly, the source eNB does not forwards the uplink RLC context to the target eNB. 

In-sequence delivery of upper layer PDUs during handover is based on a continuous PDCP SN and is provided by the 

re-ordering function at the PDCP layer, which can be activated at least during inter-eNB mobility: 

- in the downlink, the re-ordering function at the UE PDCP layer guarantees in-sequence delivery of downlink 

PDCP SDUs; 

- in the uplink, the re-ordering function at the target eNB PDCP layer guarantees in-sequence delivery of uplink 

PDCP SDUs. 

10.1.2.4 Handling in eNB 

10.1.2.5 Handling above eNB 

10.1.2.6 Mobility Management Entity (MME) 

10.1.2.7 Timing Advance 

In RRC_CONNECTED, the timing advance is not necessarily always maintained (e.g. during DRX) MAC knows if the 

L1 is synchronised and which procedure to use to start transmitting in the uplink (FFS for RRC). 

Cases where the UL synchronisation status moves from "synchronised" to "non-synchronised" include: 

- Expiration of a UE-specific timer; 

- Non-synchronised handover; 

- Explicit request by MAC or RRC in the eNB (FFS); 

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

Release 8 47 3GPP TS 36.300 V8.1.0 (2007-06)

Upon DL data arrival, dedicated signature on PRACH can be allocated by the eNB to UE. 

TA updates are signalled by the eNB to the UE in MAC PDUs addressed via C-RNTI, and embedded with user data or 

alone. 

10.1.3 Measurements 

Measurements to be performed by a UE for intra/inter-frequency mobility can be controlled by E-UTRAN, using 

broadcast or dedicated control. In RRC_IDLE state, a UE shall follow the measurement parameters defined for cell 

reselection specified by the E-UTRAN broadcast (as in UTRAN SIB). The use of dedicated measurement control for 

RRC_IDLE state is FFS. In RRC_CONNECTED state, a UE shall follow the measurement configurations specified by 

RRC directed from the E-UTRAN (e.g. as in UTRAN MEASUREMENT_CONTROL). 

Depending on whether the UE needs transmission/reception gaps to perform the relevant measurements, measurements 

are classified as gap assisted or non gap assisted. A non gap assisted measurement is a measurement on a cell that does 

not require transmission/reception gaps to allow the measurement to be performed. A gap assisted measurement is a 

measurement on a cell that does require transmission/reception gaps to allow the measurement to be performed. 

Intra-frequency neighbour (cell) measurements and inter-frequency neighbour (cell) measurements are defined as 

follows: 

- Intra-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are intrafrequency measurements when the current and target cell operates on the same carrier frequency. The UE shall 

be able to carry out such measurements without measurement gaps. 

- Inter-frequency neighbour (cell) measurements: Neighbour cell measurements performed by the UE are interfrequency measurements when the neighbour cell operates on a different carrier frequency, compared to the 

current cell. The UE should not be assumed to be able to carry out such measurements without measurement 

gaps. 

Whether a measurement is non gap assisted or gap assisted depends on the UE's capability and current operating 

frequency. The UE determines whether a particular cell measurement needs to be performed in a transmission/reception 

gap and the scheduler needs to know whether gaps are needed: 

- Same carrier frequency and cell bandwidths (Scenario A): an intra-frequency scenario; not measurement gap 

assisted. 

- Same carrier frequency, bandwidth of the target cell smaller than the bandwidth of the current cell (Scenario B): 

an intra-frequency scenario; not measurement gap assisted. 

- Same carrier frequency, bandwidth of the target cell larger than the bandwidth of the current cell (Scenario C): 

FFS. 

- Different carrier frequencies, bandwidth of the target cell smaller than the bandwidth of the current cell and 

bandwidth of the target cell within bandwidth of the current cell (Scenario D): an inter-frequency scenario; 

measurement gap-assisted scenario. 

- Different carrier frequencies, bandwidth of the target cell larger than the bandwidth of the current cell and 

bandwidth of the current cell within bandwidth of the target cell (Scenario E): an inter-frequency scenario; 

measurement gap-assisted scenario. 

- Different carrier frequencies and non-overlapping bandwidth, (Scenario F): an inter-frequency scenario; 

measurement gap-assisted scenario. 

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

Release 8 48 3GPP TS 36.300 V8.1.0 (2007-06)

current cell UE target cell

fc fc

current cell UE target cell

fc fc

Scenario D Scenario E

current cell UE target cell

fc

fc

Scenario F

Figure 10.1.3-1: Inter and Intra-frequency measurements scenarios 

Measurement gaps are provided and controlled by the network. 

10.1.3.1 Intra-frequency neighbour (cell) measurements 

In a system with frequency reuse = 1, mobility within the same frequency layer (i.e. between cells with the same carrier 

frequency) is predominant. Good neighbour cell measurements are needed for cells that have the same carrier frequency 

as the serving cell in order to ensure good mobility support and easy network deployment. Search for neighbour cells 

with the same carrier frequency as the serving cell, and measurements of the relevant quantities for identified cells are 

needed. 

NOTE: To avoid UE activity outside the DRX/DTX cycle, the reporting criteria for neighbour cell measurements 

should match the used DRX/DTX cycle. 

10.1.3.2 Inter-frequency neighbour (cell) measurements 

Regarding mobility between different frequency layers (i.e. between cells with a different carrier frequency), UE may 

need to perform neighbour cell measurements during DL/UL idle periods that are provided by DRX/DTX or packet 

scheduling (i.e. gap assisted measurements). 

NOTE: How the gaps are controlled, as well as how the scheduler knows the gaps required by the UE, is FFS. 

10.1.4 Paging and C-plane establishment 

Paging groups (where multiple UEs can be addressed) are used on L1/L2 signalling channel: 

- Precise UE identity is found on PCH; 

- DRX is UE specific. 

10.1.5 Random Access Procedure 

The random access procedure is characterized by: 

- Common procedure for FDD and TDD; 

- One procedure irrespective of cell size; 

The random access procedure is performed for the following four events: 

- Initial access from RRC_IDLE; 

- Handover requiring random access procedure; 

- DL data arrival during RRC_CONNECTED requiring random access procedure; 

- E.g. when UL synchronisation status is “non-synchronised”; 

- UL data arrival during RRC_CONNECTED requiring random access procedure; 

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

Release 8 49 3GPP TS 36.300 V8.1.0 (2007-06)

- E.g. when UL synchronisation status is “non-synchronised” or there are no dedicated scheduling request 

channels available. 

Furthermore, the random access procedure takes two distinct forms: 

- Contention based (applicable to all four events); 

- Non-contention based (applicable to only handover and DL data arrival). 

Normal DL/UL transmission can take place after the random access procedure. 

10.1.5.1 Contention based random access procedure 

The contention based random access procedure is outlined on Figure 10.1.5.1-1 below: 

Figure 10.1.5.1-1: Contention based Random Access Procedure 

The four steps of the contention based random access procedures are: 

1) Random Access Preamble on RACH in uplink: 

- 6 bits to carry: a 5 bit random ID, and 1 bit to indicate information on size of message 3 or requested resource 

blocks (FFS) limited by radio conditions. The groups of signatures that are used for indicating the 1 bit 

information, as well as necessary thresholds are broadcast on system information. 

NOTE: the total number of bits is 5 for TDD Frame Structure Type II. 

2) Random Access Response on DL-SCH: 

- Semi-synchronous (within a flexible window of which the size is one or more TTI) with message 1; 

- No HARQ; 

- Addressed to RA-RNTI on L1/L2 control channel; 

- Conveys at least RA-preamble identifier, Timing Alignment information, initial UL grant and assignment of 

Temporary C-RNTI (which may or may not be made permanent upon RRC Contention Resolution); 

- Intended for one or multiple UEs in one DL-SCH message. 

3) First scheduled UL transmission on UL-SCH: 

- Uses HARQ; 

- RLC TM: no segmentation (if RLC is involved); 

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

Release 8 50 3GPP TS 36.300 V8.1.0 (2007-06)

- For initial access: 

- Conveys at least NAS UE identifier; 

- If the size of the message allows it, the initial NAS message (or something allowing to build the initial 

NAS message in eNB) can be included; 

- Size of the message is dynamic. 

- For other events: 

- Conveys at least C-RNTI. 

4) Contention Resolution on DL-SCH: 

- Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention 

- Not synchronised with message 3; 

- Content of the message is FFS; 

- HARQ is supported; 

- Addressed to the Temporary C-RNTI on L1/L2 control channel (at least for initial access): 

- For UE in RRC_CONNECTED, the use of C-RNTI, HARQ and the consequences thereof (e.g. delay 

impact on other UEs in conjunction with HARQ) are FFS; 

- HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3, 

echoed in the RRC Contention Resolution message. 

NOTE: Contention resolution for events other than initial access needs further discussion; 

At initial access, the four steps are: 

1) Random Access Preamble on RACH; 

2) Random Access Response generated by the MAC sublayer and transmitted on DL-SCH; 

3) RRC Connection Request generated by the RRC layer and transmitted via CCCH on UL-SCH; 

4) RRC Contention Resolution generated by the RRC layer and transmitted via CCCH or DCCH (FFS) on DLSCH. 

The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a CRNTI; it is dropped by others. A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI. 

10.1.5.2 Non-contention based random access procedure 

The non-contention based random access procedure is outlined on Figure 10.1.5.2-1 below: 

UE eNB

1 RA Preamble assignment

Random Access Preamble 2

3 Random Access Response

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

Release 8 51 3GPP TS 36.300 V8.1.0 (2007-06)

Figure 10.1.5.2-1: Non-contention based Random Access Procedure 

The three steps of the non-contention based random access procedures are: 

1) Random Access Preamble assignment via dedicated signalling in DL: 

- eNB assigns to UE a 6 bit non-contention Random Access Preamble (a Random Access Preamble not within 

the set broadcasted on BCH). 

- Signalled via: 

- HO command generated by target eNB and sent via source eNB for handover; 

- MAC signalling (L1/L2 control channel or MAC control PDU is FFS) in case of DL data arrival. 

2) Random Access Preamble on RACH in uplink: 

- UE transmits the assigned non-contention Random Access Preamble. 

3) Random Access Response on DL-SCH: 

- Semi-synchronous (within a flexible window of which the size is one or more TTI) with message 1; 

- Use of HARQ is FFS; 

- Addressed either to C-RNTI or RA-RNTI (which one is FFS) on L1/L2 control channel; 

- Conveys at least: 

- Timing Alignment information and initial UL grant for handover; 

- Timing Alignment information for DL data arrival; 

- In addition, RA-preamble identifier if addressed to RA-RNTI on L1/L2 control channel. 

- Intended for: 

- Only one UE in one DL-SCH message if addressed to C-RNTI on L1/L2 control channel; 

- One or multiple UEs in one DL-SCH message if addressed to RA-RNTI on L1/L2 control channel. 

10.1.5.3 Interaction model between L1 and L2/3 for Random Access Procedure 

Random access procedure described above is modelled in Figure 10.1.5.3-1 below from L1 and L2/3 interaction point 

of view. L2/L3 receives indication from L1 whether ACK is received or DTX is detected after indication of Random 

Access Preamble transmission to L1. L2/3 indicates L1 to transmit first scheduled UL transmission (RRC Connection 

Request in case of initial access) if necessary or Random Access Preamble based on the indication from L1. 

Figure 10.1.5.3-1: Interaction model between L1 and L2/3 for Random Access Procedure 

10.1.6 Radio Link Failure 

Two phases governs the behaviour associated to radio link failure as shown on Figure 10.1.6: 

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

Release 8 52 3GPP TS 36.300 V8.1.0 (2007-06)

- First phase: 

- started upon radio problem detection; 

- leads to radio link failure detection; 

- no UE-based mobility; 

- based on timer or other (e.g. counting) criteria (T1). 

- Second Phase: 

- started upon radio link failure detection; 

- leads to RRC_IDLE; 

- UE-based mobility; 

- Timer based (T2). 

Figure 10.1.6: Radio Link Failure 

Table 10.1.6 below describes how mobility is handled with respect to radio link failure: 

Table 10.1.6: Mobility and Radio Link Failure 

Cases First Phase Second Phase T2 expired 

UE returns to the same cell Continue as if no radio 

problems occurred 

Activity cannot be resumed 

without interaction between UE 

and eNB 

Procedure to be used is FFS 

Normally not via RRC_IDLE 

Go via RRC_IDLE 

UE selects a different cell 

from the same eNB 

N/A FFS Go via RRC_IDLE 

UE selects a cell of a 

different eNB 

N/A Go via RRC_IDLE Go via RRC_IDLE 

10.1.7 Radio Access Network Sharing 

E-UTRAN shall support radio access network sharing based on support for multi-to-multi relationship between EUTRAN nodes and EPC nodes (S1-flex). 

If the E-UTRAN is shared by multiple operators, the system information broadcasted in each shared cell contains the 

PLMN-id of each operator (up to 6) and a single tracking area code (TAC) valid within all the PLMNs sharing the radio 

access network resources. 

The UE shall be able to read up to 6 PLMN-ids, to select one of the PLMN-ids at initial attachment and to indicate this 

PLMN-id to the E-UTRAN in subsequent instances of the Random Access procedures (e.g. as defined in subclause 

10.1.5). The E-UTRAN shall select an appropriate MME for the PLMN indicated by the UE. Once attached to an 

MME, the UE shall be able to indicate the allocated MME in subsequent instances of the Random Access procedures. 

Whether the indication of the selected PLMN or the allocated MME is contained in the temporary UE identity or 

signalled separately is FFS. 

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

Release 8 53 3GPP TS 36.300 V8.1.0 (2007-06)

Handling of area restrictions for UE in LTE_ACTIVE shall follow the principles specified in sub-clause 10.4. 

10.1.8 Handling of Roaming and Area Restrictions for UEs in LTE_ACTIVE 

Handling of roaming/area restrictions and handling of subscription specific preferences in LTE_ACTIVE is performed 

in the eNB based on information provided by the EPC over the S1 interface. 

10.2 Inter RAT 

10.2.1 Cell reselection 

A UE in RRC_IDLE performs cell reselection. The principles of this procedure are as follows: 

- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process: 

- Only the frequency needs to be indicated to enable the UE to search and measure UTRA neighbouring cells; 

- It is FFS if there is a need to indicate each neighbouring GSM cell in the serving cell system information to 

enable the UE to search and measure a cell or if it is sufficient to indicate the list of BCCH frequencies 

(range); 

- Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria. The 

criteria and rules relating to which measurements may be omitted are FFS; 

- Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which 

involves measurements of the serving and neighbour cells. Details of the cell reselection criteria are FFS; 

- For UTRA neighbouring cells, there is no need to indicate cell-specific cell reselection parameters i.e. these 

parameters are common to all neighbouring cells on a UTRA frequency; 

- For GSM neighbouring cells, the need to indicate cell-specific cell reselection parameters is FFS; 

- Cell reselection parameters are applicable to all UEs in a cell, but it is possible to configure specific reselection 

parameters per UE group or per UE. 

Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for 

cells “reserved for operator use”) applicable for mobiles in RRC_IDLE mode. 

When performing cell reselection while the UE is camped on another RAT, the principles of this procedure are as 

follows: 

- The UE measures attributes of the E-UTRA neighbouring cells: 

- Only the carrier frequencies need to be indicated to enable the UE to search and measure E-UTRA 

neighbouring cells; 

- Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which 

involves measurements of the serving and neighbour cells. Details of the cell reselection criteria are FFS; 

- For E-UTRA neighbouring cells, there is no need to indicate cell-specific cell reselection parameters i.e. 

these parameters are common to all neighbouring cells on an E-UTRA frequency; 

- Cell reselection parameters are applicable to all UEs in a cell, but it is possible to configure specific reselection 

parameters per UE group or per UE. 

- It should be possible to prevent the UE from reselecting to specific detected neighbouring cells. The details of 

the mechanism are FFS; 

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

Release 8 54 3GPP TS 36.300 V8.1.0 (2007-06)

10.2.2 Handover 

Inter RAT HO is designed so that changes to GERAN and UTRAN are minimised. This can be done by following the 

principles specified for GERAN to/from UTRAN intersystem HO. In particular the following principles are applied to 

E-UTRAN Inter RAT HO design: 

1. Inter RAT HO is network controlled through source access system. The source access system decides about 

starting the preparation and provides the necessary information to the target system in the format required by the 

target system. That is, the source system adapts to the target system. The actual handover execution is decided in 

the source system. 

2. Inter RAT HO is backwards handover, i.e. radio resources are prepared in the target 3GPP access system before 

the UE is commanded by the source 3GPP access system to change to the target 3GPP access system. 

3. To enable backwards handover, and while RAN level interfaces are not available, a control interface exists in 

CN level. In Inter RAT HO involving E-UTRAN access, this interface is between 2G/3G SGSN and 

corresponding MME/Serving Gateway. 

4. The target access system will be responsible for giving exact guidance for the UE on how to make the radio 

access there (this includes radio resource configuration, target cell system information etc.). This information is 

given during the handover preparation and should be transported completely transparently through the source 

access system to the UE. 

5. Mechanisms for avoiding or mitigating the loss of user data (e.g. forwarding or bi-casting) may be used until the 

3GPP Anchor determines that it can send DL U-plane data directly to the target system. 

6. The handover procedure should not require any UE to CN signalling in order for data to start to flow in the target 

system. This requires that the security context, UE capability context and QoS context is transferred (or 

translated) within the network between source and target system. 

7. Similar handover procedure should apply for handovers of both real time and non-real time services. 

8. Similar handover procedure should apply for both Inter RAT Handover and intra-LTE Handover with EPC node 

change. 

10.2.3 Measurements 

10.2.3.1 Inter-RAT handovers from E-UTRAN 

Measurements to be performed by a UE for inter-RAT mobility can be controlled by E-UTRAN, using broadcast or 

dedicated control. In RRC_CONNECTED state, a UE shall follow the measurement parameters specified by RRC or 

MAC commands (FFS) directed from the E-UTRAN (e.g. as in UTRAN MEASUREMENT_CONTROL). 

UE performs inter-RAT neighbour cell measurements during DL/UL idle periods that are provided by the network 

through suitable DRX/DTX period or packet scheduling if necessary. 

NOTE: How the gaps are controlled, as well as how the scheduler knows the gaps required by the UE, is FFS. 

10.2.3.2 Inter-RAT handovers to E-UTRAN 

From UTRAN, UE performs E-UTRAN measurements by using idle periods created by compressed mode 

(CELL_DCH), FACH measurement occasions (CELL_FACH - FFS), or DRX (other states). 

From GERAN, E-UTRAN measurements are performed in the same way as WCDMA measurements for handover to 

UTRAN: E-UTRAN measurements are performed in GSM idle frames in a time multiplexed manner. However, it 

should be discussed with GERAN how to ensure that inter-RAT measurements do not take too much measurement time, 

while the requested 3GPP inter-RAT measurements can be performed well enough. 

Design constraints of 3GPP inter-RAT measurements should be considered when L1 details of E-UTRAN concept are 

defined. 

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

Release 8 55 3GPP TS 36.300 V8.1.0 (2007-06)

10.2.3.3 Inter-RAT cell reselection from E-UTRAN 

In RRC_IDLE state, a UE shall follow the measurement parameters specified by the E-UTRAN broadcast (as in 

UTRAN SIB). The use of dedicated measurement control is FFS. 

10.2.3.4 Limiting measurement load at UE 

Introduction of E-UTRA implies co-existence of various UE capabilities. Each UE may support different combinations 

of RATs, e.g., E-UTRA, UTRA, GSM, and non-3GPP RATs, and different combinations of frequency bands, e.g., 800 

MHz, 1.7 GHz, 2 GHZ, etc. Moreover, some UEs may support the full E-UTRA spectrum bandwidth of 20 MHz, 

whereas some UEs may support only a part of 20 MHz. Despite such heterogeneous environment, the measurement 

load at UE should be minimised. To limit the measurement load and the associated control load: 

- E-UTRAN can configure the RATs to be measured by UE; 

- The number of measurement criteria (event and periodic reporting criteria) should be limited (as in TS 25.133 

subclause 8.3.2 [7]); 

- E-UTRAN should be aware of the UE capabilities for efficient measurement control, to prevent unnecessary 

waking up of the measurement entity; 

- The UE capabilities should be categorised to prevent diversion of capabilities and conformance test scenarios, 

FFS; 

- Support for blind HO (i.e., HO without measurement reports from UE) is FFS. 

10.2.4 Network Aspects 

10.3 Inter 3GPP access system mobility 

10.3.1 Cell reselection 

10.3.2 Handover 

10.3.3 Measurements 

10.4 Area Restrictions 

Information on which area restrictions to be applied during LTE_ACTIVE state is provided by the MME at context 

setup over the S1 interface. 

The eNB shall store the UE restriction information and use it to determine whether the UE has access to radio resources 

in the E-UTRAN. The source eNB should apply restriction handling when selecting a target eNB. 

The available UE restriction information shall be propagated by the source eNB over X2 at intra E-UTRAN handover. 

11 Scheduling and Rate Control 

In order to utilise the SCH resources efficiently, a scheduling function is used in MAC. In this subclause, an overview 

of the scheduler is given in terms of scheduler operation, signalling of scheduler decisions, and measurements to 

support scheduler operation. 

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

Release 8 56 3GPP TS 36.300 V8.1.0 (2007-06)

11.1 Basic Scheduler Operation 

MAC in eNB includes dynamic resource schedulers that allocate physical layer resources for the DL-SCH and UL-SCH 

transport channels. Different schedulers operate for the DL-SCH and UL-SCH. 

The scheduler should take account of the traffic volume and the QoS requirements of each UE and associated radio 

bearers, when sharing resources between UEs. Only “per UE” grants are used to grant the right to transmit on the ULSCH (i.e. there are no “per UE per RB” grants). 

Schedulers may assign resources taking account the radio conditions at the UE identified through measurements made 

at the eNB and/or reported by the UE. 

Radio resource allocations can be valid for one or multiple TTIs. 

Resource assignment consists of physical resource blocks (PRB) and MCS. Allocations for time periods longer than one 

TTI might also require additional information (allocation time, allocation repetition factor...). 

11.1.1 Downlink Scheduling 

In the downlink, E-UTRAN can dynamically allocate resources (PRBs and MCS) to UEs at each TTI via the C-RNTI 

on L1/L2 control channel(s). A UE always monitors the L1/L2 control channel(s) in order to find possible allocation 

when its downlink reception is enabled (activity governed by DRX). 

In addition, E-UTRAN can allocate predefined downlink resources for the first HARQ transmissions to UEs. When 

required, retransmissions are explicitly signalled via the L1/L2 control channel(s). In the sub-frames where the UE has 

been pre-assigned resources, if the UE cannot find its C-RNTI on the L1/L2 control channel(s), a downlink transmission 

according to any pre-defined allocation that the UE has been assigned in the TTI is assumed. As a result, the UE 

performs blind decoding of the pre-defined resources (the subset of pre-defined resources shall be set in accordance to 

UE’s capability). Otherwise, in the sub-frames where the UE has been pre-assigned resources, if the UE finds its CRNTI on the L1/L2 control channel(s), the L1/L2 control channel allocation overrides the pre-defined allocation for that 

TTI and the UE does not perform blind decoding of the pre-defined resources. 

11.1.2 Uplink Scheduling 

In the uplink, E-UTRAN can dynamically allocate resources (PRBs and MCS) to UEs at each TTI via the C-RNTI on 

L1/L2 control channel(s). A UE always monitors the L1/L2 control channel(s) in order to find possible allocation for 

uplink transmission when its downlink reception is enabled (activity governed by DRX). 

In addition, E-UTRAN can allocate a predefined uplink resource for the first HARQ transmissions and potentially 

retransmissions to UEs. In the sub-frames where the UE has been pre-assigned resource, if the UE cannot find its CRNTI on the L1/L2 control channel(s), an uplink transmission according to the pre-defined allocation that the UE has 

been assigned in the TTI can be made. The network performs decoding of the pre-defined PRBs according to the predefined MCS. Otherwise, in the sub-frames where the UE has been pre-assigned resource, if the UE finds its C-RNTI 

on the L1/L2 control channel(s), the L1/L2 control channel allocation overrides the pre-defined allocation for that TTI 

and the UE’s transmission follows the L1/L2 control, not the pre-defined allocation. Retransmissions are either 

implicitly allocated in which case the UE uses the pre-defined allocation, or explicitly allocated via L1/L2 control 

channel(s) in which case the UE does not follow the pre-defined allocation. 

11.2 Void 

11.3 Measurements to Support Scheduler Operation 

Measurement reports are required to enable the scheduler to operate in both uplink and downlink. These include 

transport volume and measurements of a UEs radio environment. The time and frequency granularity of the UE radio 

environment measurement reports is FFS. 

Uplink buffer status reports are needed to provide support for QoS-aware packet scheduling. Uplink buffer status 

reports refer to the data that is buffered in the logical channel queues in the UE MAC. The uplink packet scheduler in 

the eNB is located at MAC level. Uplink buffer status reports may be transmitted using MAC signalling (e.g. as a 

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

Release 8 57 3GPP TS 36.300 V8.1.0 (2007-06)

specific type of MAC control PDU). A way to separately signal buffer status reports for different QoS classes may be 

used. To define the exact content of buffer status reports and the possible use of physical layer signalling are FFS. 

The buffer reporting scheme used in uplink should be flexible in order to support different types of data services. The 

buffer reporting criteria are setup and reconfigured on a per user basis or per radio bearer basis (FFS) using RRC or 

MAC signalling (FFS). The use of System Information should also be considered for the initial setup of default buffer 

reporting criteria (on a per cell basis). Constraints on how often uplink buffer reports are signalled from the UEs can be 

specified by the network to limit the overhead from sending the reports in the uplink. 

It is FFS whether additional measurement information is required to support the classification of UEs between localised 

and distributed resource allocation. 

It is FFS whether additional measurement information is required to support cell center / cell-edge resource subdivision. 

11.4 Rate Control of GBR, MBR, and AMBR 

11.4.1 Downlink 

The eNB enforces the downlink MBR associated with a GBR bearer and the downlink AMBR associated with a group 

of Non-GBR bearers. 

11.4.2 Uplink 

The UE has an uplink rate control function which manages the sharing of uplink resources between radio bearers. RRC 

controls the uplink rate control function by giving each bearer a priority and a prioritised bit rate (PBR). In addition, an 

MBR per GBR bearer is also provided. The values signalled may not be related to the ones signalled via S1 to the eNB. 

The uplink rate control function ensures that the UE serves its radio bearer(s) in the following sequence: 

1. All the radio bearer(s) in decreasing priority order up to their PBR; 

2. All the radio bearer(s) in decreasing priority order for the remaining resources assigned by the grant and the 

function ensures that the MBR is not exceeded. 

NOTE1: In case the PBRs are all set to zero, the first step is skipped and the radio bearer(s) are served in strict 

priority order: the UE maximises the transmission of higher priority data. 

NOTE2: By limiting the total grant to the UE, the eNB can ensure that the AMBR is not exceeded. 

If more than one radio bearer has the same priority, the UE shall serve these radio bearers equally. 

12 DRX in RRC_CONNECTED 

In order to enable reasonable UE battery consumption, DRX in E-UTRAN is characterised by the following: 

- Per UE mechanism (as opposed to per radio bearer); 

- No RRC or MAC substate to distinguish between different levels of DRX; 

- Available DRX values are controlled by the network and start from non-DRX up to x seconds. Value x may be as 

long as the paging DRX used in LTE_IDLE. Detailed values are FFS; 

- Measurement requirement and reporting criteria can differ according to the length of the DRX interval i.e. long 

DRX intervals may experience more relaxed requirements; 

- The network may send a threshold indicating to the UE that it does not need to make measurements of 

neighbouring cells if the radio quality of the serving cell (exact definition of the radio quality and possible 

dependency on DRX value is FFS) is above the threshold; 

- Irrespective of DRX, UE may use first available RACH opportunity to send an UL measurement report; 

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

Release 8 58 3GPP TS 36.300 V8.1.0 (2007-06)

- Immediately after sending a measurement report, the UE may change its DRX. This mechanism would be preconfigured by the eNB; 

- HARQ operation related to UL data transmission is independent of DRX operation. Whether HARQ operation of 

DL data is independent of DRX operation is FFS; 

- When DRX is configured, the UE may be further configured with an "on-duration" during which time the UE 

monitors the L1/L2 control channels for possible allocations; 

- When DRX is configured, CQI reports can only be sent by the UE during the “on-duration”; 

- A timer in the UE is used to detect need for obtaining timing advance. 

For NRT services, during the "on-duration", if the UE cannot find an allocation, it reenters DRX (hereafter referred to 

as initial DRX). However, if the L1/L2 control signalling signals an allocation to the UE, the UE enters non-DRX 

mode: 

- until a MAC header/control message tells the UE to re-enter DRX, with a cycle explicitely indicated in the MAC 

payload; or 

- the UE autonomously re-enters DRX with a predefined cycle after not receiving any allocation for a given 

duration. The predefined DRX cycle may be shorter than the initial one. And if it is, a longer period of inactivity 

will bring the UE back to the initial DRX cycle directly or by successive steps (FFS). 

13 QoS 

13.1 QoS concept and bearer service architecture 

The SAE bearer service layered architecture is depicted in Figure 13.1 below: 

Figure 13.1: SAE Bearer Service Architecture 

The SAE Bearer Service is used to provide the edge-to-edge QoS for service data flows. The SAE bearer consists of a 

SAE radio bearer and a SAE access bearer. The SAE Radio Bearer Service provides the transport of the SAE Bearer 

Service data units between eNB and UE according to the SAE QoS profile associated with each SAE bearer. The SAE 

Access Bearer Service provides the transport of the SAE Bearer Service data units between Serving Gateway and eNB 

according to the SAE QoS profile associated with each SAE bearer. 

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

Release 8 59 3GPP TS 36.300 V8.1.0 (2007-06)

With respect to E-UTRAN, the following principles apply: 

- There is a one-to-one mapping between an SAE Bearer and an SAE Radio Bearer; 

- There is a one-to-one mapping between an SAE Radio Bearer and a logical channel. 

13.2 Resource establishment and QoS signalling 

14 Security 

14.1 Overview and Principles 

The following principles apply to E-UTRAN security: 

- The eNB keys are cryptographically separated from the EPC keys used for NAS protection (making it 

impossible to use the eNB key to figure out an EPC key). 

- The keys are derived in the EPC/UE from key material that was generated by a NAS (EPC/UE) level AKA 

procedure. 

- The eNB keys are sent from the EPC to the eNB when the UE is entering LTE_ACTIVE state (i.e. during RRC 

connection or S1 context setup). 

- Key material for the eNB keys is sent between the eNBs during LTE_ACTIVE intra-E-UTRAN mobility. 

- A sequence number is used as input to the ciphering and integrity protection. A given sequence number must 

only be used once for a given eNB key (except for identical re-transmission). The same sequence number can be 

used for both ciphering and integrity protection. 

- A hyper frame number (HFN) (i.e. an overflow counter mechanism) is used in the eNB and UE in order to limit 

the actual number of sequence number bits that is needed to be sent over the radio. The HFN needs to be 

synchronized between the UE and eNB. 

As a result of an AKA run, the EPC and the UE share a base-key named K_ASME. From K_ASME, the NAS, (and 

indirectly) K_eNB keys are derived. The K_ASME never leaves the EPC, but the K_eNB key is transported to the eNB 

from the EPC when the UE transitions to LTE_ACTIVE. From the K_eNB, the eNB and UE can derive the UP and 

RRC keys. When the UE goes into LTE_IDLE or LTE_DETACHED, the K_eNB, UP and RRC keys are deleted from 

the eNB. The key hierarchy is depicted on Figure 14.1-1 below: 

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

Release 8 60 3GPP TS 36.300 V8.1.0 (2007-06)

USIM / AuC

UE / MME

UE / ASME

KASME

K

CK, IK

KeNB-UP-enc KeNB-RRC- int

KNAS int KeNB

UE / HSS

UE / eNB

KNAS enc

KeNB-RRC-enc

Figure 14.1-1: Key Hierarchy 

14.2 Security termination points 

The table below describes the security termination points. 

Table 14.2 Security Termination Points 

 Ciphering Integrity Protection 

NAS Signalling Required and terminated in MME Required and terminated in MME 

U-Plane Data Required and terminated in eNB Not Required 

(NOTE 1) 

RRC Signalling (AS) Required and terminated in eNB Required and terminated in eNB 

MAC Signalling (AS) Not required (NOTE 2) Not required (NOTE 2) 

NOTE 1: Integrity protection for U-Plane is not required and thus it is not supported between UE and Serving 

Gateway or for the transport of user plane data between eNB and Serving Gateway on S1 interface. 

NOTE 2: SA3 needs to further study on whether buffer status reports from UEs to the eNBs in MAC layer need to 

be protected. 

15 MBMS 

For MBMS, the following definitions are introduced: 

MBSFN Synchronization Area: An area of the network where all NodeBs/eNodeBs can be synchronized and perform 

MBSFN transmissions. MBSFN Synchronization Areas are capable of supporting one or more MBSFN Areas. On a 

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

Release 8 61 3GPP TS 36.300 V8.1.0 (2007-06)

given frequency layer, a NodeB/eNodeB can only belong to one MBSFN Synchronization Area. MBSFN 

Synchronization Areas are independent from the definition of MBMS Service Areas 

MBSFN Transmission or a transmission in MBSFN mode: a simulcast transmission technique realised by 

transmission of identical waveforms at the same time from multiple cells. An MBSFN Transmission from multiple cells 

within the MBSFN Area is seen as a single transmission by a UE. 

MBSFN Area: a MBSFN Area consists of a group of cells within an MBSFN Synchronization Area of a network, 

which are co-ordinated to achieve a MBSFN Transmission. A cell within an MBSFN Synchronization Area may form 

part of multiple MBSFN Areas, each characterized by different transmitted content and participating set of cells. 

Figure 15-1: MBMS Definitions 

MBSFN Area Transmitting and Advertising Cell: A cell within a MBSFN Area which is contributing to the MBSFN 

Transmission and advertises within the cell the availability of the MBSFN Transmission. 

MBSFN Area Transmitting-Only Cell: A cell within a MBSFN Area which is contributing to the MBSFN 

Transmission but does not advertise within the cell the availability of the MBSFN Transmission. The need for this type 

of cell is FFS. 

MBSFN Area Reserved Cell: A cell within a MBSFN Area which does not contribute to the MBSFN Transmission. 

The cell may be allowed to transmit for other services but at restricted power on the resource allocated for the MBSFN 

transmission e.g. PTP for users at the centre of the cell. 

15.1 General 

In E-UTRAN, MBMS can be provided on a frequency layer dedicated to MBMS (set of cells dedicated to MBMS 

transmission i.e. set of "MBMS dedicated cells") and/or on a frequency layer shared with non-MBMS services (set of 

cells supporting both unicast and MBMS transmissions i.e. set of “Unicast/MBMS mixed cells”). In both cases, single 

frequency network mode of operation is possible for MBMS transmission. 

MBMS reception is possible for UEs in RRC_CONNECTED, MBMS_RRC_CONNECTED or RRC_IDLE states. The 

term MBMS_RRC_CONNECTED is described in sub-clause 15.3.4 below. 

The overall U-plane architecture of content synchronization is shown in Figure 15.1-1. This architecture is based on the 

functional allocation for Unicast and the SYNC protocol layer is defined additionally on transport network layer to 

support content synchronization mechanism. 

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

Release 8 62 3GPP TS 36.300 V8.1.0 (2007-06)

RLC

MAC

PHY

UE

E-MBMS 

Gateway 

eNB

M1

RLC

MAC

PHY

eBM-SC

MBMS 

packet

MBMS 

packet

TNL TNL TNL

SYNC SYNC

SYNC: Protocol to synchronise 

data used to generate a certain 

radio frame

Figure A15.1-1: The overall u-plane architecture of the MBMS content synchronization 

The SYNC protocol is defined as a protocol to carry additional information that enable eNBs to identify the timing for 

radio frame transmission and detect packet loss. The SYNC protocol is applicable to DL and may be specified as a part 

of GTP-U, or as an independent protocol. 

If PDCP (Header Compression) is used, it is located in the E-MBMS GW (FFS for single-cell operation and localized 

service). 

Complying with the content synchronization mechanism is required for an eNB distributing a MBMS service for MultiCell transmission. An eNB transmitting a service in single cell only should not be required to comply with the stringent 

timing requirements indicated by SYNC protocol. 

15.2 MBMS Cells 

An E-UTRAN cell supporting MBMS is either an MBMS-dedicated cell or an MBMS/Unicast-mixed cell. 

It is FFS how the MCCH is transmitted in the cell. 

15.2.1 MBMS-dedicated cell 

When a cell belongs to a frequency layer dedicated to MBMS transmission: 

- MTCH and MCCH are mapped on MCH or DL-SCH (FFS) for p-t-m transmission; 

- No uplink; 

- No counting mechanism in another (unicast) cell supported; 

- No support for unicast data transfer in the cell; 

- The occurrence of paging messages on the frequency layer dedicated to MBMS transmission is FFS: 

- If paging messages were allowed, the UE could answer in a non-E-UTRA cell e.g. UTRA cell (FFS); 

15.2.2 MBMS/Unicast-mixed cell 

When a cell does not belong to a frequency layer dedicated to MBMS transmission: 

- MTCH and MCCH are mapped on MCH or DL-SCH for p-t-m transmission; 

- Transmission of both unicast and MBMS in the cell is done in a co-ordinated manner. 

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

Release 8 63 3GPP TS 36.300 V8.1.0 (2007-06)

15.3 MBMS Transmission 

15.3.1 General 

Transmission of MBMS in E-UTRAN is either a single-cell transmission or a multi-cell transmission. 

To avoid unnecessary MBMS transmission in a cell where there is no MBMS user, the network can detect the presence 

in a cell of at least one MBMS user interested in the MBMS service e.g. by polling. It is FFS whether or not it is needed 

to count to a greater granularity the number of UEs in a cell interested in an MBMS service. 

15.3.2 Single-cell transmission 

Single-cell transmission of MBMS is characterized by: 

- MBMS is transmitted only on the coverage of a specific cell; 

- Combining of MBMS transmission from multiple cells is not supported; 

- MTCH and MCCH are mapped on DL-SCH for p-t-m transmission; 

- Scheduling is done by the eNB; 

- Multiple UEs can be allocated dedicated uplink feedback channels identical to those used in unicast transmission, 

which enables them to report HARQ Ack/Nack and CQI. Where such a feedback mechanism is configured, 

AMC is applied, and HARQ retransmissions are made on DL-SCH using a group (service specific) RNTI in a 

time frame that is co-ordinated with the original MTCH transmission. All UEs are able to receive the 

retransmissions and combine them with the original transmissions at the HARQ level. 

- UEs that are allocated a dedicated uplink feedback channel are in either RRC_CONNECTED state or 

MBMS_RRC_CONNECTED state. 

For single-cell transmission, an eNB is not required to comply with the stringent timing requirements indicated by 

SYNC protocol. The following principles still applies for the single transmission:. 

1. An E-MBMS GW sends/broadcasts MBMS packet with the SYNC protocol to each eNB transmitting the 

service. 

2. The SYNC protocol provides additional information so that the eNBs identify the transmission radio frame(s). 

The E-MBMS GW does not need accurate knowledge of radio resource allocation in terms of exact time division 

(e.g. exact start time of the radio frame transmission). 

3. The segmentation/concatenation is needed for MBMS packets and should be totally up to the RLC/MAC layer in 

eNB, without taking into account any indication in the SYNC protocol.. 

NOTE: The usage of SYNC protocol for single cell localized services is for further study. 

15.3.3 Multi-cell transmission 

Multi-cell transmission of MBMS is characterized by: 

- Synchronous transmission of MBMS within its MBSFN Area; 

- Combining of MBMS transmission from multiple cells is supported; 

- MTCH and MCCH are mapped on MCH for p-t-m transmission; 

- The MBSFN Transmitting, Advertising, and Reserved cells are either semi-statically configured e.g. by O&M 

(MBMS-dedicated cell or MBMS/Unicast-mixed cell), or are dynamically adjusted (MBMS/Unicast-mixed cell) 

e.g. based on counting mechanisms (FFS). 

- The MBSFN Synchronization Area is semi-statically configured e.g. by O&M. The MBSFN Area can be semistatically configured by O&M or (FFS) dynamically configured by MCE. 

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

Release 8 64 3GPP TS 36.300 V8.1.0 (2007-06)

- Scheduling is done by the MBMS Coordination Entity (MCE). 

- It is FFS whether UEs receiving MBSFN transmission will be able to take part in a feedback mechanism of the 

type described for single cell transmission, to enable re-transmissions to be made via the DL-SCH of the cell. 

Should such a re-transmission mechanism be supported, all UEs that are receiving the MBSFN transmission will 

be able to receive the re-transmissions and combine them with the original transmission at a HARQ level. 

The content synchronization for multi-cell transmission is provided by the following principles: 

1. All eNBs in a given MBSFN Synchronization Area have a synchronised radio frame timing such that the radio 

frames are transmitted at the same time. 

2. All eNBs have the same configuration of RLC/MAC/PHY for each MBMS service. These are indicated in 

advance by the MCE. 

3. An E-MBMS GW sends/broadcasts MBMS packet with the SYNC protocol to each eNB transmitting the 

service. 

4. The SYNC protocol provides additional information so that the eNBs identify the transmission radio frame(s). 

The E-MBMS GW does not need accurate knowledge of radio resource allocation in terms of exact time division 

(e.g. exact start time of the radio frame transmission). 

5. eNB buffers MBMS packet and waits for the transmission timing indicated in the SYNC protocol. 

6. The segmentation/concatenation is needed for MBMS packets and should be totally up to the RLC/MAC layer in 

eNB. 

7. The SYNC protocol provides means to detect packet loss(es) and supports a recovery mechanism robust against 

loss of consecutive PDU packets (MBMS Packets with SYNC Header). 

8. (FFS) For the packet loss case the transmission of radio blocks potentially impacted by the lost packet should be 

muted or padded. 

9. (FFS) The mechanism supports indication or detection of MBMS data burst termination (e.g. to identify and 

alternately use available spare resources related to pauses in the MBMS PDU data flow). 

15.3.4 MBMS Reception States 

UEs that are receiving MTCH transmissions without taking part in an MBMS feedback mechanism can be in 

RRC_IDLE or RRC_CONNECTED state, the state being defined solely by its non-MBMS status. 

UEs that are receiving MTCH transmissions and are taking part in at least one MBMS feedback scheme will be in 

RRC_CONNECTED state (UE also has Unicast services active) or MBMS_RRC_CONNECTED state (UE does not 

have Unicast service active)..

The MBMS_RRC_CONNECTED state has the following characteristics: 

- There is no S1 connection for the UE, 

- The UE has a C-RNTI 

- The UE can make measurement reports. 

- The RRC connection does not survive cell change, 

- There is no handover preparation, the UE performs cell change. It is FFS whether the target cell can be informed 

prior to a UE’s cell change in order to enable a faster availability of the MBMS service in the target cell, 

For UEs that are in RRC_CONNECTED state, normal mobility procedures apply. In this case, the transfer of MBMS 

information in the UE context on X2 interface is TBD.

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

Release 8 65 3GPP TS 36.300 V8.1.0 (2007-06)

16 Radio Resource Management aspects 

The purpose of radio resource management (RRM) is to ensure the efficient use the available radio resources and to 

provide mechanisms that enable E-UTRAN to meet radio resource related requirements identified in sub-clause 10 of 

3GPP TR 25.913 [2]. In particular, RRM in E-UTRAN provides means to manage (e.g. assign, re-assign and release) 

radio resources taking into account single and multi-cell aspects. 

16.1 RRM functions 

16.1.1 Radio Bearer Control (RBC) 

The establishment, maintenance and release of Radio Bearers involve the configuration of radio resources associated 

with them. When setting up a radio bearer for a service, radio bearer control (RBC) takes into account the overall 

resource situation in E-UTRAN, the QoS requirements of in-progress sessions and the QoS requirement for the new 

service. RBC is also concerned with the maintenance of radio bearers of in-progress sessions at the change of the radio 

resource situation due to mobility or other reasons. RBC is involved in the release of radio resources associated with 

radio bearers at session termination, handover or at other occasions. 

RBC is located in the eNB. 

16.1.2 Radio Admission Control (RAC) 

The task of radio admission control (RAC) is to admit or reject the establishment requests for new radio bearers. In 

order to do this, RAC takes into account the overall resource situation in E-UTRAN, the QoS requirements, the priority 

levels and the provided QoS of in-progress sessions and the QoS requirement of the new radio bearer request. The goal 

of RAC is to ensure high radio resource utilization (by accepting radio bearer requests as long as radio resources 

available) and at the same time to ensure proper QoS for in-progress sessions (by rejecting radio bearer requests when 

they cannot be accommodated). 

RAC is located in the eNB. 

16.1.3 Connection Mobility Control (CMC) 

Connection mobility control (CMC) is concerned with the management of radio resources in connection with idle or 

active mode mobility. In idle mode, the cell reselection algorithms are controlled by setting of parameters (thresholds 

and hysteresis values) that define the best cell and/or determine when the UE should select a new cell. Also, E-UTRAN 

broadcasts parameters that configure the UE measurement and reporting procedures. In active mode, the mobility of 

radio connections has to be supported. Handover decisions may be based on UE and eNB measurements. In addition, 

handover decisions may take other inputs, such as neighbour cell load, traffic distribution, transport and hardware 

resources and Operator defined policies into account. 

CMC is located in the eNB. 

16.1.4 Dynamic Resource Allocation (DRA) - Packet Scheduling (PS) 

The task of dynamic resource allocation (DRA) or packet scheduling (PS) is to allocate and de-allocate resources 

(including buffer and processing resources and resource blocks (i.e. chunks)) to user and control plane packets. DRA 

involves several sub-tasks, including the selection of radio bearers whose packets are to be scheduled and managing the 

necessary resources (e.g. the power levels or the specific resource blocks used). PS typically takes into account the QoS 

requirements associated with the radio bearers, the channel quality information for UEs, buffer status, interference 

situation, etc. DRA may also take into account restrictions or preferences on some of the available resource blocks or 

resource block sets due to inter-cell interference coordination considerations. 

DRA is located in the eNB. 

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

Release 8 66 3GPP TS 36.300 V8.1.0 (2007-06)

16.1.5 Inter-cell Interference Coordination (ICIC) 

Inter-cell interference coordination has the task to manage radio resources (notably the radio resource blocks) such that 

inter-cell interference is kept under control. ICIC is inherently a multi-cell RRM function that needs to take into account 

information (e.g. the resource usage status and traffic load situation) from multiple cells. The preferred ICIC method 

may be different in the uplink and downlink. 

ICIC is located in the eNB. 

16.1.6 Load Balancing (LB) 

Load balancing has the task to handle uneven distribution of the traffic load over multiple cells. The purpose of LB is 

thus to influence the load distribution in such a manner that radio resources remain highly utilized and the QoS of inprogress sessions are maintained to the extent possible and call dropping probabilities are kept sufficiently small. LB 

algorithms may result in hand-over or cell reselection decisions with the purpose of redistribute traffic from highly 

loaded cells to underutilized cells. 

LB is located in the eNB. 

16.1.7 Inter-RAT Radio Resource Management 

Inter-RAT RRM is primarily concerned with the management of radio resources in connection with inter-RAT 

mobility, notably inter-RAT handover. At inter-RAT handover, the handover decision may take into account the 

involved RATs resource situation as well as UE capabilities and Operator policies. The importance of Inter-RAT RRM 

may depend on the specific scenario in which E-UTRAN is deployed. Inter-RAT RRM may also include functionality 

for inter-RAT load balancing for idle and active mode UEs. 

16.2 RRM architecture 

16.2.1 Centralised Handling of certain RRM Functions 

16.2.2 De-Centralised RRM 

Historical information about the UE is transferred between the eNBs over the X2 interface during the handover 

preparation procedure. Exact information to be transferred will be decided on case by case basis, and is left for stage 3 

work.

16.2.3 Load balancing control 

17 RF aspects 

17.1 Spectrum deployments 

18 UE capabilities 

RRC signalling carries RRC capability and NAS signalling carries NAS capability. Some capability information may be 

stored in the EPC. In the uplink, some capability information may be sent early in e.g. 

RRC_CONNECTION_REQUEST. In the downlink, inquiry procedure of the UE capability may be supported. 

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

Release 8 67 3GPP TS 36.300 V8.1.0 (2007-06)

19 S1 Interface 

19.1 S1 User plane 

The S1 user plane interface (S1-U) is defined between the eNB and the SAE GW. The S1-U interface provides non 

guaranteed delivery of user plane PDUs between the eNB and the SAE GW. The user plane protocol stack on the S1 

interface is shown in Figure 19.1. The transport network layer is built on IP transport and GTP-U is used on top of 

UDP/IP to carry the user plane PDUs between the eNB and the SAE GW. 

GTP-U 

UDP 

IP 

Data link layer 

User plane PDUs 

Physical layer 

Figure 19.1: S1 Interface User Plane (eNB-SAE GW) 

19.2 S1 Control Plane 

The S1 control plane interface (S1-MME) is defined between the eNB and the MME. The control plane protocol stack 

of the S1 interface is shown on Figure 19.2. The transport network layer is built on IP transport, similarly to the user 

plane but for the reliable transport of signalling messages SCTP is added on top of IP. The application layer signalling 

protocol is referred to as S1-AP (S1 Application Protocol). 

SCTP 

IP 

Data link layer 

S1-AP 

Physical layer 

Figure 19.2: S1 Interface Control Plane (eNB-MME) 

The SCTP layer provides the guaranteed delivery of application layer messages. 

In the transport IP layer point-to-point transmission is used to deliver the signalling PDUs. 

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

Release 8 68 3GPP TS 36.300 V8.1.0 (2007-06)

A single SCTP association per S1-MME interface instance shall be used with one pair of stream identifiers for S1-

MME common procedures. Only a few pairs of stream identifiers should be used for S1-MME dedicated procedures. 

The upper limit for the number of stream identifiers for dedicated procedures is FFS and will be decided during the 

stage 3 work. 

MME communication context identifiers that are assigned by the MME for S1-MME dedicated procedures and eNB 

communication context identifiers that are assigned by the eNB for S1-MME dedicated procedures shall be used to 

distinguish UE specific S1-MME signalling transport bearers. The communication context identifiers are conveyed in 

the respective S1-AP messages. 

19.2.1 S1 Interface Functions 

Note: The following list of S1 functions reflects the status of agreements in RAN3, might be extended in 

forthcoming meetings. 

- SAE Bearer Service Management function:

- Setup, Modify, release. 

- Mobility Functions for UEs in LTE_ACTIVE: 

- Intra-LTE Handover; 

- Inter-3GPP-RAT Handover. 

- S1 Paging function: 

- NAS Signalling Transport function; 

- S1-interface management functions: 

- Error indication. 

- Network Sharing Function; 

- Roaming and Area Restriction Support function; 

- NAS Node Selection Function; 

- Initial Context Setup Function. 

19.2.1.1 S1 Paging function 

The paging function supports the sending of paging requests to all cells of the TA(s) the UE is registered. 

Paging requests are sent to the relevant eNBs according to the mobility information kept in the UE’s MM context in the 

serving MME. 

19.2.1.2 S1 UE Context Management function 

In order to support UEs in LTE_ACTIVE, UE contexts need to be managed, i.e. established and released in the eNodeB 

and in the EPC to support user individual signalling on S1. 

19.2.1.3 Initial Context Setup Function 

NOTE: The naming of the function/procedure is left to be FFS. 

The Initial Context Setup function supports the establishment of the necessary overall initial UE Context including SAE 

Bearer context, Security context, roaming restriction, UE capability information, UE S1 signalling connection ID, etc. 

in the eNB to enable fast Idle-to-Active transition. 

In addition to the setup of overall initial UE Contexts, Initial Context Setup function also supports the piggy-backing of 

the corresponding NAS messages. Initial Context Setup is initiated by the MME. 

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

Release 8 69 3GPP TS 36.300 V8.1.0 (2007-06)

19.2.1.4 Mobility Functions for UEs in LTE_ACTIVE 

19.2.1.4.1 Intra-LTE Handover 

The Intra-LTE-Handover function supports mobility for UEs in LTE_ACTIVE and comprises the preparation, 

execution and completion of handover via the X2 and S1 interfaces. 

 19.2.1.4.2 Inter-3GPP-RAT Handover 

The Inter-3GPP-RAT Handover function supports mobility to and from other 3GPP-RATs for UEs in LTE_ACTIVE 

and comprises the preparation, execution and completion of handover via the S1 interface. 

19.2.1.5 SAE Bearer Service Management function 

The SAE Bearer Service management function is responsible for establishing, modifying and releasing E-UTRAN 

resources for user data transport once a UE context is available in the eNB. The establishment and modification of EUTRAN resources is triggered by the MME and requires respective QoS information to be provided to the eNB. The 

release of E-UTRAN resources is triggered by the MME either directly or following a request received from the eNB 

(optional). 

NOTE: Whether SAE bearer related NAS messages are included in S1AP SAE Bearer Management procedures 

piggybacking or if NAS messages are sent with S1-AP Direct Transfer is FFS: 

19.2.1.6 NAS Signalling Transport function 

The NAS Signalling Transport function provides means to transport a NAS message (e.g. for NAS mobility 

management) for a specific UE on the S1 interface. 

19.2.1.7 NAS Node Selection Function 

The interconnection of eNBs to multiple MME/Serving SAE-GWs is supported in the LTE/SAE architecture. Therefore 

a NAS node selection function is located in the eNB to determine the MME association of the UE, based on the UE’s 

temporary identifier, which was assigned to the UE by the MME. 

This functionality is located in the eNB only and enables proper routing via the S1 interface. On S1, no specific 

procedure corresponds to the NAS Node Selection Function. 

19.2.2 S1 Interface Signalling Procedures 

Note: The following list of S1 procedures reflects the status of agreements in RAN3, might be extended in 

forthcoming meetings. 

- SAE Bearer signalling procedures: 

- SAE Bearer Setup procedure; 

- SAE Bearer Modification procedure; 

- SAE Bearer Release procedure (MME initiated); 

- SAE Bearer Release procedure (eNB initiated). 

- Handover signalling procedures; 

- Handover Preparation procedure;

- Handover Resource Allocation procedure; 

- Handover Completion procedure; 

- Handover Cancellation procedure. 

- Paging procedure; 

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

Release 8 70 3GPP TS 36.300 V8.1.0 (2007-06)

- NAS transport procedure: 

- UL direction (Initial UE Message); 

- UL direction (Uplink NAS transport); 

- DL direction (Downlink NAS transport). 

- Error Indication procedure: 

- E-UTRAN initiated error indication procedure; 

- EPC initiated error indication procedure. 

- Initial Context Setup procedure; 

19.2.2.1 Paging procedure 

Figure 19.2.2.1: Paging procedure 

The MME initiates the paging procedure by sending the PAGING message to each eNB with cells belonging to the 

tracking area(s) in which the UE is registered. Each eNB can contain cells belonging to different tracking areas, 

whereas each cell can only belong to one TA. 

The paging response back to the MME is initiated on NAS layer and is sent by the eNB based on NAS-level routing 

information. 

19.2.2.2 S1 UE Context Release procedure 

The S1 UE Context Release procedure causes the eNB to remove all UE individual signalling resources and the related 

user data transport resources. This procedure is initiated by the EPC and may be triggered on request of the serving 

eNB. 

19.2.2.2.1 S1 UE Context Release (EPC triggered) 

Figure 19.2.2.2.1: S1 UE Context Release procedure (EPC triggered) 

- The EPC initiates the UE Context Release procedure by sending the S1 UE Context Release Command towards 

the E-UTRAN. The eNodeB releases all related signalling and user data transport resources. 

eNB MME 

[S1AP] PAGING 

Paging Response (NAS means) 

eNB EPC 

[S1AP] S1 UE Context Release Command 

[S1AP] S1 UE Context Release Complete 

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

Release 8 71 3GPP TS 36.300 V8.1.0 (2007-06)

- The eNB confirms the S1 UE Context Release activity with the S1 UE Context Release Complete message. 

- In the course of this procedure the EPC releases all related resources as well, except context resources in the 

EPC for mobility management and the default SAE Bearer configuration. 

19.2.2.2.2 S1 UE Context Release Request (eNB triggered) 

The S1 UE Context Release Request procedure is initiated for E-UTRAN internal reasons and comprises the following 

steps: 

- The eNB sends the S1 UE Context Release Request message to the EPC. 

- The EPC triggers the EPC initiated UE context release procedure. 

Figure 19.2.2.2.2: S1 UE Context Release Request procedure (eNB triggered) 

and subsequent S1 UE Context Release procedure (EPC triggered) 

19.2.2.3 Initial Context Setup procedure 

NOTE: The naming of the function/procedure is left to be FFS. 

The Initial Context Setup procedure establishes the necessary overall initial UE context in the eNB in case of an Idle-to 

Active transition. The Initial Context Setup procedure is initiated by the MME. 

The Initial Context Setup procedure comprises the following steps: 

- The MME initiates the Initial Context Setup procedure by sending INITIAL CONTEXT SETUP REQUEST to 

the eNB. This message may include general UE Context (e.g. security context, roaming restrictions, UE 

capability information, UE S1 signalling connection ID, etc.), SAE bearer context (Serving SAE-GW TEID, 

QoS information), and may be piggy-backed with the corresponding NAS message. 

- Upon receipt of INITIAL CONTEXT SETUP REQUEST, the eNB setup the context of the associated UE, and 

perform the necessary RRC signalling towards the UE, e.g. Radio Bearer Setup procedure. 

- The eNB responds with INITIAL CONTEXT SETUP COMPLETE to inform a successful operation, and with 

INITIAL CONTEXT SETUP FAILURE to inform an unsuccessful operation. 

[S1AP] EPC initiated 

eNB EPC 

[S1AP] S1 UE Context Release Request 

[S1AP] S1 UE Context Release Command 

[S1AP] S1 UE Context Release Complete 

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

Release 8 72 3GPP TS 36.300 V8.1.0 (2007-06)

UE eNB MME

RACH preamble

RACH response

RRC: Connection Request

(NAS: Service Request)

S1-AP: INITIAL CONTEXT SETUP COMPLETE

+ eNB UE signalling connection ID

+ Bearer Setup Confirm (eNB TEID)

S1-AP: INITIAL UE MESSAGE (FFS)

+ NAS: Service Request

+ eNB UE signalling connection ID

S1-AP: INITIAL CONTEXT SETUP REQUEST

+ (NAS message)

+ MME UE signalling connection ID

+ Security Context

+ UE Capability Information (FFS)

+ Bearer Setup (Serving SAE-GW TEID, QoS 

profile)

RRC: Contention Resolution

RRC: Radio Bearer Setup

(NAS Message)

RRC: Radio Bearer Setup Complete

Paging

Paging

Figure 19.2.2.3: Initial Context Setup procedure (highlighted in blue) in Idle-to-Active procedure 

19.2.2.4 SAE Bearer signalling procedures 

19.2.2.4.1 SAE Bearer Setup procedure 

Figure 19.2.2.4.1-1: SAE Bearer Setup procedure 

The SAE Bearer Setup procedure is initiated by the MME to support: 

- Assignment of resources to a dedicated SAE bearer. 

- Assignment of resources for a default SAE bearer (FFS) 

- Setup of SAE Access bearer (on S1) and SAE Radio Bearer (on Uu) 

The SAE Bearer Setup procedure comprises the following steps: 

- The SAE BEARER SETUP REQUEST is sent by the MME to the eNB to setup resources on S1 and Uu for one 

or several SAE Bearer(s). The SAE BEARER SETUP REQUEST message contains the Serving SAE GW TEID 

and QoS indicator(s) per SAE bearer within the SAE Bearer Setup List. 

RRC: Radio Bearer Setup

UE eNB MME 

S1-AP: SAE BEARER SETUP RESPONSE 

SAE Bearer Setup List: SAE Bearer ID, TEID eNB 

SAE Beaer Failed to Setup List: SAE Bearer ID

S1-AP: SAE BEARER SETUP REQUEST 

SAE Bearer Setup List: SAE Bearer ID, QoS, TEID 

Serving SAE GW 

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

Release 8 73 3GPP TS 36.300 V8.1.0 (2007-06)

- Upon receipt of the SAE BEARER SETUP REQUEST the eNB establishes the SAE Radio Bearer(s) (RRC: 

Radio Bearer Setup) and resources for SAE Access bearers. 

- The eNB responds with a SAE BEARER SETUP RESPONSE messages to inform whether the setup of 

resources and establishment of an SAE Bearer was successful or unsuccessful, with the SAE bearer Setup (SAE 

Bearer ID , eNB TEID) and the SAE Bearer Failed to Setup list (SAE bearer ID). The eNB also creates the 

binding between the SAE Access bearer(s) (DL/UL TEID) and the SAE Radio Bearer(s). 

19.2.2.4.2 SAE Bearer Modification procedure 

Figure 19.2.2.4.2-1: SAE Bearer Modification procedure 

The SAE Bearer Modification procedure is initiated by the MME to support the modification of already established 

SAE Bearer configurations: 

- Modify of SAE Access bearer (on S1) and SAE Radio Bearer (on Uu) 

The SAE Bearer Modification procedure comprises the following steps: 

- The SAE BEARER MODIFY REQUEST is sent by the MME to the eNB to modify one or several SAE 

Bearer(s). The SAE BEARER MODIFY REQUEST message contains the QoS indicator(s) and Serving SAEGW TEID per SAE bearer in the SAE Bearer Modify List. 

- Upon receipt of the SAE BEARER MODIFY REQUEST the eNB modifies the SAE Radio Bearer configuration 

(RRC procedure to modify the Radio bearer). 

- The eNB responds with a SAE BEARER MODIFY RESPONSE message to inform whether the SAE Bearer 

modification has succeeded or not indicating with the SAE bearer Modify list and SAE bearer Failed to Modify 

list. With SAE Bearer ID(s) in the SAE Bearer Modify List the eNB identifies the SAE bearer(s) successfully 

modified or failed to modify.. 

19.2.2.4.3 SAE Bearer Release procedure (MME initiated) 

RRC: Radio Modify Setup

UE eNB MME 

S1-AP: SAE BEARER MODIFY RESPONSE 

SAE Bearer Modify List: SAE Bearer ID, eNB TEID 

SAE Beaer Failed to Modify List: SAE Bearer ID

S1-AP: SAE BEARER MODIFY REQUEST 

SAE Bearer Modify List: SAE Bearer ID, QoS, Serving 

SAE GW TEID 

RRC: Radio Bearer Release 

UE eNB MME 

S1-AP: SAE BEARER RELEASE COMPLETE 

SAE Bearer Release List: SAE Bearer ID 

SAE Bearer Failed to Release List: SAE Bearer ID

S1-AP: SAE BEARER RELEASE COMMAND 

SAE Bearer Release List: SAE Bearer ID 

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

Release 8 74 3GPP TS 36.300 V8.1.0 (2007-06)

Figure 19.2.2.4.3-1: SAE Bearer Release procedure (MME initiated) 

The SAE Bearer Release procedure is initiated by the MME to release resources for the the indicated SAE Bearers. 

The SAE Bearer Release procedure comprises the following steps: 

- The SAE BEARER RELEASE COMMAND is sent by the MME to the eNB to release resources on S1 and Uu 

for one or several SAE Bearer(s).. With the SAE Bearer ID(s) in the SAE bearer Release List contained in SAE 

BEARER RELEASE COMMAND the MME identifies, the SAE Access Bearer(s) to be released. 

- Upon receipt of the SAE BEARER RELEASE COMMAND the eNB releases the SAE Radio Bearers (RRC: 

RAdio bearer relese) and SAE Access bearers. 

- The eNB responds with a SAE BEARER RELEASE COMPLETE message containing SAE bearer Release list 

and SAE bearer Failed to Release list. With the SAE Bearer IDs in the SAE Bearer Release List/SAE Bearer 

Failed to Release List the eNB identifies the SAE bearer(s) successfully released or failed to release. 

19.2.2.4.4 SAE Bearer Release procedure (eNB initiated) 

Figure 19.2.2.4.4-1: SAE Bearer Release (eNB initiated) procedure 

The SAE Bearer Release function enables the E-UTRAN to request the release of resources for one or several SAE 

Bearers. The eNB initiated SAE Bearer Release procedure comprises the following steps: 

- The eNB initiates the SAE Bearer Release procedure by sending the SAE BEARER RELEASE REQUEST 

message to the MME in order to release of one or more SAE Bearer(s). With the SAE Bearer ID(s) in the SAE 

Bearer Relase List the eNB identifies the SAE bearer(s) requested to be released. The SAE BEARER RELEASE 

REQUEST message shall include the reason to release the resources for the SAE bearer, for example user 

inactivity. 

- Upon receipt the MME initiates the SAE Bearer Release procedure (SAE BEARER RELEASE 

COMMAND/SAE BEARER RELEASE COMPLETE) to request release of resources for the SAE Bearer(s). 

19.2.2.5 Handover signalling procedures 

Handover signalling procedures support both, inter-eNB handover and inter-RAT handover. 

Inter-RAT handovers shall be initiated via the S1 interface. 

Inter-eNB handovers shall be initiated via the X2 interface except if any of the following conditions are true: 

- there is no X2 between source and target eNB.

- the source eNB has been configured to initiate handover to the particular target eNB via S1 interface in 

order to enable the change of an EPC node (MME and/or Serving SAE-GW).

- the source eNB has attempted to start the inter-eNB HO via X2 but receives a negative reply from the 

target eNB with a specific cause value. 

NOTE: Handling of cases where the target eNB does not reply is FFS. 

Inter-eNB handovers shall be initiated via the S1 interface, if one of the above conditions applies.

RRC: Radio Bearer Release 

UE eNB MME 

S1-AP: SAE BEARER RELEASE COMPLETE 

SAE Bearer Release List: SAE Bearer ID 

SAE Bearer Failed to Release List: SAE Bearer ID

S1-AP: SAE BEARER RELEASE COMMAND 

SAE Bearer Relase List: SAE Bearer ID 

S1-AP: SAE BEARER RELEASE REQUEST 

SAE Bearer Release List: SAE Bearer ID

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

Release 8 75 3GPP TS 36.300 V8.1.0 (2007-06)

NOTE: Affects on Home eNBs should be looked at. 

Its forseen to re-use Handover principles from the Iu interface for inter-eNB handovers which are initiated via the S1 

interface. 

19.2.2.5.1 Handover Preparation procedure 

The Handover preparation procedure is initiated by the source eNB if it determines the necessity to initiate the handover 

via the S1 interface. 

Figure 19.2.2.5.1-1: Handover preparation procedure 

The handover preparation comprises the following steps: 

- The HANDOVER REQUIRED message is sent to the MME. 

- The handover preparation phase is finished upon the reception of the HANDOVER COMMAND in the source 

eNB, which includes at least radio interface related information (HO Command for the UE), and successfully 

established SAE Bearer(s). 

- In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the 

MME responds with the HANDOVER PREPARATION FAILURE message instead of the HANDOVER 

COMMAND message. 

19.2.2.5.2 Handover Resource Allocation procedure 

The handover resource allocation comprises the following steps: 

Figure 19.2.2.5.2-1: Handover resource allocation procedure 

RRC: HANDOVER COMMAND S1-AP: HANDOVER COMMAND 

Source eNB MME 

S1-AP: HANDOVER REQUIRED 

UE 

S1-AP: HANDOVER PREPARATION 

FAILURE 

S1-AP: HANDOVER REQUEST ACK 

Target eNB MME 

S1-AP: HANDOVER REQUEST 

UE 

S1-AP: HANDOVER FAILURE 

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

Release 8 76 3GPP TS 36.300 V8.1.0 (2007-06)

- The MME sends the HANDOVER REQUEST message including the SAE Bearer(s) which needs to be setup by 

the target eNB. 

- The target eNB responds with the HANDOVER REQUEST ACK message after the required resources for all 

accepted SAE Bearers are allocated. The HANDOVER REQUEST ACK message contains at least successfully 

established SAE bearer(s) and radio interface related information (HO Command for the UE), which is later sent 

transparently via the EPC/CN from the target RAT to the source RAT. 

- If no resources are available on the target side, the target eNB responds with the HANDOVER FAILURE 

message instead of the HANDOVER REQUEST ACK message. 

19.2.2.5.3 Handover Completion procedure 

The Handover Completion comprises the following steps: 

- The HANDOVER COMPLETE message is sent by the target eNB when the UE has successfully been 

transferred to the target cell. 

Figure 19.2.2.5.3-1: Handover completion procedure 

19.2.2.5.4 Handover Cancellation 

This functionality is located in the source eNB to allow a final decision regarding the outcome of the handover, i.e. 

either to proceed or to cancel the handover procedure. 

Figure 19.2.2.5.4-1: Handover cancellation procedure 

- The source eNB sends a HANDOVER CANCEL message to the MME indicating the reason for the handover 

cancellation. 

- The MME confirms the reception of the HANDOVER CANCEL message by returning the HANDOVER 

CANCEL ACK message. 

19.2.2.6 NAS transport procedures 

A NAS signalling message is transferred on the S1 interface in both directions. The procedures providing this 

functionality are 

- Initial UE Message procedure (eNB initiated) 

RRC: HANDOVER CONFIRM 

Target eNB MME 

S1-AP: HANDOVER COMPLETE 

UE 

S1-AP: HANDOVER CANCEL ACK 

Source eNB MME 

S1-AP: HANDOVER CANCEL 

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

Release 8 77 3GPP TS 36.300 V8.1.0 (2007-06)

- Uplink NAS transport procedure (eNB initiated) 

- Downlink NAS transport procedure (MME initiated) 

i) Initial UE Message procedure 

eNB MME 

S1-AP: INITIAL UE MESSAGE 

Figure 19.2.2.6-1: Initial UE Message procedure 

- The INITIAL UE MESSAGE procedure is initiated by the eNB by sending the INITIAL UE MESSAGE 

message to the MME. The INITIAL UE MESSAGE contains a NAS message (e.g. Service Request), the UE 

signalling reference ID and other S1 addressing information. 

:ii) NAS Transport procedure (eNB initiated). 

eNB MME 

S1-AP: UPLINK NAS TRANSPORT 

Figure 19.2.2.6-2: Uplink NAS Transport procedure 

- The Uplink NAS Transport procedure is initiated by the eNB by sending the UPLINK NAS TRANSPORT 

message to the MME. The UPLINK NAS TRANSPORT message contains a NAS message, UE identification 

and other S1 related addressing information. 

iii) NAS Transport procedure (MME initiated) 

S1-AP: DOWNLINK NAS TRANSPORT 

eNB MME 

Figure 19.2.2.6-3: Downlink NAS Transport procedure 

- The Downlink NAS Transport procedure is initiated by the MME by sending the DOWNLINK NAS 

TRANSPORT message to the eNB. The DOWNLINK NAS TRANSPORT contains a NAS message, UE 

identification and other S1 related addressing information. 

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

Release 8 78 3GPP TS 36.300 V8.1.0 (2007-06)

20 X2 Interface 

20.1 User Plane 

The X2 user plane interface (X2-U) is defined between eNBs. The X2-U interface provides non guaranteed delivery of 

user plane PDUs. The user plane protocol stack on the X2 interface is shown in Figure X. The transport network layer is 

built on IP transport and GTP-U is used on top of UDP/IP to carry the user plane PDUs. 

The X2-UP interface protocol stack is identical to the S1-UP protocol stack. 

GTP-U 

UDP 

IP 

Data link layer 

User plane PDUs 

Physical layer 

Figure 20.1-1: X2 Interface User Plane (eNB-eNB) 

20.2 Control Plane 

The X2 control plane interface (X2-CP) is defined between two neighbour eNBs. The control plane protocol stack of 

the X2 interface is shown on Figure 20.2 below. The transport network layer is built on SCTP on top of IP. The 

application layer signalling protocol is referred to as X2-AP (X2 Application Protocol). 

Note: Exact naming of application protocol FFS. 

SCTP 

IP 

Data link layer 

X2-AP 

Physical layer 

Figure 20.2: X2 Interface Control Plane 

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

Release 8 79 3GPP TS 36.300 V8.1.0 (2007-06)

A single SCTP association per X2-C interface instance shall be used with one pair of stream identifiers for X2-C 

common procedures. Only a few pairs of stream identifiers should be used for X2-C dedicated procedures. The upper 

limit for the number of stream identifiers for dedicated procedures is FFS and will be decided during the stage 3 work. 

Source-eNB communication context identifiers that are assigned by the source-eNB for X2-C dedicated procedures, and 

target-eNB communication context identifiers that are assigned by the target-eNB for X2-C dedicated procedures, shall 

be used to distinguish UE specific X2-C signalling transport bearers. The communication context identifiers are 

conveyed in the respective X2AP messages. 

20.2.1 X2-CP Functions 

The X2AP protocol supports the following functions: 

- Intra LTE-Access-System Mobility Support for UE in LTE_ACTIVE: 

- Context transfer from source eNB to target eNB; 

- Control of user plane tunnels between source eNB and target eNB; 

- Handover cancellation. 

- Uplink Load Management; 

- General X2 management and error handling functions: 

- Error indication. 

20.2.2 X2-CP Procedures 

The elementary procedures supported by the X2AP protocol are listed in Table 20.2.2 below: 

Table 20.2.2: X2-CP Procedures 

Elementary 

Procedure 

Initiating 

Message 

Response Message of 

Successful Outcome 

Response Message of 

Unsuccessful Outcome Description & comments 

Handover 

Preparation 

HANDOVER 

REQUEST 

HANDOVER 

SUCCESS 

HANDOVER FAILURE Used by source eNB to request a 

handover to the target eNB 

Handover 

Cancellation 

HANDOVER 

CANCEL 

FFS Used by the source eNB to cancel a 

previously requested handover in a 

target eNB 

Release 

Resource 

RELEASE 

RESOURCE 

- - Used by the target eNB to signal to 

source eNB that control plane 

resources for the handed over UE 

context can be released. 

Error 

Indication 

ERROR 

INDICATION 

- - Used by the eNB to report errors in 

a received message provided they 

cannot be reported by an 

appropriate response message. 

Load 

Management 

LOAD 

INDICATOR 

- - Used by the eNB to report its load 

conditions to its neighbour eNBs. 

Note: this initial list might be extended. 

20.2.3 Inter-cell Load Management 

Inter-cell load management in E-UTRAN is performed through the X2 interface. In case of variation in the load 

condition, the eNodeB signals the new load condition to its neighbor eNodeBs e.g. the neighbor eNodeBs for which an 

X2 interface is configured due to mobility reasons. 

The LOAD INDICATOR message is used to signal the load conditions between eNodeBs. 

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

Release 8 80 3GPP TS 36.300 V8.1.0 (2007-06)

[X2 AP] LOAD INDICATOR 

eNB eNB 

Figure 20.2.3-1: LOAD INDICATOR message over X2 

21 System and Terminal complexity 

21.1 Overall System complexity 

21.2 Physical layer complexity 

21.3 UE complexity 

22 Support for self-configuration and self-optimisation 

22.1 Definitions 

This concept includes several different functions from eNB activation to radio parameter tuning. Figure 22.1-1 is a basic 

framework for all self-configuration /self-optimization functions. 

Self-configuration process is defined as the process where newly deployed nodes are configured by automatic 

installation procedures to get the necessary basic configuration for system operation. 

This process works in pre-operational state. Pre-operational state is understood as the state from when the eNB is 

powered up and has backbone connectivity until the RF transmitter is switched on. 

As described in Figure 21.1, functions handled in the pre-operational state like: 

- Basic Setup and 

- Initial Radio Configuration 

are covered by the Self Configuration process. 

NOTE: depending on the final chosen functional distribution in RAN, the feasibility of following items should be 

studied e.g.: 

- To obtain the necessary interface configuration; 

- Automatic registration of nodes in the system can be provided by the network; 

- Alternative possibilities for nodes to obtain a valid configuration; 

- The required standardization scope. 

Self-optimization process is defined as the process where UE & eNB measurements and performance measurements 

are used to auto-tune the network. 

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

Release 8 81 3GPP TS 36.300 V8.1.0 (2007-06)

This process works in operational state. Operational state is understood as the state where the RF interface is 

additionally switched on. 

As described in Figure 21.1, functions handled in the operational state like: 

- Optimization / Adaptation 

are covered by the Self Optimization process. 

NOTE: depending on the final chosen functional distribution in RAN the feasibility of following items should be 

studied e.g.: 

- The distribution of data and measurements over interfaces relevant to RAN3; 

- Functions/entities/nodes in charge of data aggregation for optimization purpose; 

- Dependencies with O&M and O&M interfaces, in the self optimization process; 

- The required standardization scope. 

The architecture of logical self-configuration/optimization functionality is FFS. 

Figure 22.1-1: Ramifications of Self-Configuration /Self-Optimization functionality 

22.2 UE Support for self-configuration and self-optimisation 

UE shall support measurements and procedures which can be used for self-configuration and self-optimisation of the EUTRAN system. 

- UE shall support measurements and measurement reporting to support self-optimisation of the E-UTRAN 

system. Measurements and reports used for the normal system operation, should be used as input for the selfoptimisation process as far as possible. 

NOTE: the UE impact should be carefully investigated and taken into account. 

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

Release 8 82 3GPP TS 36.300 V8.1.0 (2007-06)

- The network is able to configure the measurements and the reporting for self-optimisation support by RRC 

signalling messages. 

- It shall be possible to associate measurements for self-optimisation purpose with location information depending 

on UE capability (details are [FFS]). 

22.3 Self-configuration 

22.3.1 Dynamic configuration of the S1-MME interface 

22.3.1.1 Prerequisites 

The following prerequisites are assumed: 

- An initial remote IP end point to be used for SCTP initialisation is provided to the eNB for each MME in the pre 

operational state. 

How the eNB gets the remote IP end point(s) and its own IP adress are FFS. 

- Other relevant information from/to eNB to/from MME to self-configure S1-MME are FFS 

22.3.1.2 SCTP initialization 

- For each MME the eNodeB tries to initialize a SCTP association as described in RFC2960 [8], using a known 

initial remote IP Endpoint as the starting point, until SCTP connectivity is established. 

22.3.1.3 Application layer initialization 

Once SCTP connectivity has been established, the eNodeB and MME are in a position to exchange application level 

configuration data over the S1-MME application protocol needed for the two nodes to interwork correctly on the S1 

interface. The details of the information exchange outlined below are FFS, and dependent on the further standardization 

of the S1 interface. 

- The eNodeB provides the relevant information to the MME , which may include node ID, list of supported TA(s), 

etc. Details of the relevant information needed to setup the S1-MME interface is subject to stage3 discussion and 

is left FFS. 

- The MME provides the relevant information to the eNodeB, which may include node ID, PLMN ID, etc. Details 

of the relevant information needed to setup the S1-MME interface is subject to stage3 discussion and is left FFS. 

- When the application layer initialization is successfully concluded, and has been mutually acknowledged by the 

two peer nodes, the dynamic configuration procedure is completed, and the S1-MME interface is operational. 

23 Others 

23.1 Support for real time IMS services 

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

Release 8 83 3GPP TS 36.300 V8.1.0 (2007-06)

Annex A (informative): 

NAS Overview 

This subclause provides for information an overview on services and functions provided by the NAS control protocol.. 

A.1 Services and Functions 

The main services and functions of the NAS sublayer include: 

- SAE Bearer control (see 3GPP TR 23.882 [6]); 

- LTE_IDLE mobility handling; 

- Paging origination; 

- Configuration and control of Security. 

A.2 NAS protocol states & state transitions 

The NAS control protocol uses the following states: 

- LTE_DETACHED: 

- No RRC entity. 

- LTE_IDLE: 

- RRC_IDLE State; 

- Some information is stored in the UE and in the network: 

- IP address, etc; 

- Security association (keys, etc); 

- UE capability information (FFS); 

- Radio Bearers (FFS); 

- State transition decided in eNB or EPC (FFS); 

- LTE_ACTIVE: 

- RRC_CONNECTED State; 

- State transition decided in eNB or EPC (FFS); 

The following figure reflects how the NAS states relate to the RRC: 

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

Release 8 84 3GPP TS 36.300 V8.1.0 (2007-06)

Power-Up

LTE_DETACHED

RRC: NULL

RRC Context in network:

- Does not exist

Allocated UE-Id(s):

- IMSI

UE position:

- Not known by network

Mobility

- PLMN/Cell selection

DL/UL activity:

- None

LTE_ACTIVE

RRC: RRC_CONNECTED

RRC Context in network:

- Includes all information necessary for

communication

Allocated UE-Id(s): 

- IMSI

- ID unique in Tracking Area (TA-ID)

- ID unique in cell (C-RNTI)

- 1 or more IP addresses

UE position: 

- Known by network at cell level

Mobility:

- Handover

DL/UL activity: 

- UE may be configured with DRX/DTX

periods

LTE_IDLE

RRC: RRC_IDLE

Context in network:

- Includes information to enable fast

transition to LTE_ACTIVE (e.g.

security key information)

Allocated UE-Id(s): 

- IMSI 

- ID unique in Tracking Area (TA-ID)

- 1 or more IP addresses

UE position:

- Known by network at Tracking Area

(TA) level

Mobility:

- Cell reselection

DL activity: 

- UE is configured with DRX period

Perform “Registration”

- Allocate C-RNTI, TA-ID, IP addr

- Perform Authentication

- Establish security relation

Change of PLMN/deregistration

- Deallocate C-RNTI, TA-ID, IP address

New traffic

- Allocate C-RNTI

Inactivity

- Release C-RNTI

- Allocate DRX for PCH

Timeout of periodic TA-update

- Deallocate TA-ID, IP address

Figure A.2: E-UTRAN RRC protocol states 

NOTE: The applicability of the ID unique in Tracking Area (TAID) in LTE_DETACHED is FFS. 

The UE context in the EPC will discriminate the 3 states. The UE context in the eNB will only exist in the 

LTE_ACTIVE state. 

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

Release 8 85 3GPP TS 36.300 V8.1.0 (2007-06)

Annex B (informative): 

MAC and RRC Control 

The E-UTRA supports control signalling in terms of MAC control signalling (L1/L2 control channel and MAC control 

PDU) and RRC control signalling (RRC message). 

B.1 Difference between MAC and RRC control 

The different characteristics of MAC and RRC control are summarized in the table below. 

Table B.1: Summary of the difference between MAC and RRC control 

 MAC control RRC control 

Control entity MAC RRC 

Signalling L1/L2 control channel MAC control PDU RRC message 

Signalling reliability ~ 10-2 (no retransmission) ~ 10-3 (after HARQ) ~ 10-6 (after ARQ) 

Control delay Very short Short Longer 

Extensibility None or very limited Limited High 

Security No integrity protection 

 No ciphering 

No integrity protection 

No ciphering 

Integrity protected 

Ciphering (FFS) 

The main difference between MAC and RRC control lies in the signalling reliability. Due to the signalling reliability, 

signalling involving state transitions and radio bearer configurations should be performed by RRC. Basically, all 

signalling performed by RRC in UTRA should also be performed by RRC also for E-UTRA. 

B.2 Classification of MAC and RRC control functions 

The table below illustrates the classification of MAC and RRC control functions for E-UTRAN. 

Table B.2: Classification of MAC and RRC control functions 

 Controlled configuration/parameters 

MAC 

control 

signalling 

L1/L2 

control 

channel 

Short-lived (PRB) and dynamic (MCS) allocation 

Long-lived (PRB) and fixed (MCS) allocation (FFS) 

Timing Advance (FFS) 

MAC control 

PDU 

Timing Advance (FFS) 

RLC related control PDU (FFS) 

RRC control 

signalling 

RRC 

message 

Long-lived (PRB) and fixed (MCS) allocation (FFS) 

Activation/deactivation of long-lived (PRB) and/or fixed (MCS) allocation (FFS) 

TTI configuration for variable TTI length control (FFS) 

Static parameter configuration for UE inactivity control within RRC_ACTIVE (e.g. 

DRX/DTX periods) 

 

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

Release 8 86 3GPP TS 36.300 V8.1.0 (2007-06)

Annex C (informative): 

System Information 

This annex provides an overview of the classification and division of system information between static and flexible 

parts. Considerations about dedicated distribution of system information are also included. 

C.1 SI classification 

Five categories are identified for system information classification: 

1. Information valid across multiple cells; 

2. Information needed at cell/PLMN search; 

3. Information needed prior to cell camping; 

4. Information needed before cell access; 

5. Information needed while camping on a cell. 

From UEs’ point of view, the information that is needed at cell selection and prior to camping are very similar. Before a 

UE can camp on a cell, it needs to know if the access is allowed in that cell. Thus it would be very beneficial to know 

all access restrictions already at cell search phase. 

C.1.1 Information valid across multiple cells 

The pieces of information that can be valid across multiple cells are: 

- A-GNSS assistance data; 

- PLMN identity(ies); 

- Tracking area identity; 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Predefined configuration information; 

- System Frame Number if it does not change from cell to cell (in case of synchronized network); 

- Some measurement/mobility information (FFS). 

C.1.2 Information needed at cell/PLMN search 

In order to support full mobility within the serving frequency layer, the UEs need to perform cell search rather often and 

thus it is seen very important that the information needed in cell search phase is readily available, thereby improving 

cell search times and minimizing UE power consumption. If system information decoding is needed for identifying a 

cell, fast system information reception is needed in order to avoid too long identification times. For optimising PLMN 

search and make PLMN search fast and non-complex, the information needed for PLMN search should be easily 

available. The pieces of information that are needed at cell/PLMN search are: 

- PLMN identity(ies): in order to acquire information to which PLMN the cell belongs, UEs need to receive 

PLMN identity(ies); 

NOTE: There may be multiple PLMN identities for one cell. 

- Measurement cell identity (FFS): there needs to be a cell identity in the system information, in order to allow 

UEs to identify the cell reliably for measurement purposes. 

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

Release 8 87 3GPP TS 36.300 V8.1.0 (2007-06)

NOTE: UEs may identify the cell also based on the reference sequence detection; 

There is another cell identity that identifies the cell within e.g. PLMN. 

NOTE: UEs may have to check possible cell access restrictions before selecting cell/PLMN; 

For cell/PLMN search UEs might need some L1 parameters. 

C.1.3 Information needed prior to cell camping 

Before a UE can camp on a cell, it needs to know any access related parameters in order to avoid camping on cells 

where access is forbidden. Thus prior to camping on a cell, a UE needs to know the following information: 

- Any cell access restriction parameters, e.g.: 

- Tracking area identity: if the forbidden TA concept is adopted from legacy systems, then the UE needs to 

know whether the cell belongs to such forbidden TA. 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Cell barring status and cell reservation status (FFS if needed per PLMN): the UE needs to know whether the 

cell is barred or reserved in order to avoid camping on a barred cell. Possibly also barring time might be 

needed in order to avoid UE to poll barring time frequently from the system information. Another option is 

that barring status is indicated also in the neighbour cell list. 

- Radio access limitation parameters: 

- Any radio condition parameters that limit the access to the cell e.g. similar to GSM C1/S criteria; 

- It is FFS if we need to have some band information indication also, in order to allow UEs to check 

possible band support before camping on the cell. 

NOTE: UE may need some L1 parameters prior to camping. 

C.1.4 Information needed prior to cell access 

Once a UE has camped on a cell, the information needed prior to cell access (transmission/reception) includes at least: 

- System Frame Number (SFN) (FFS) 

- SFN is probably needed by the UE to understand the scheduling parameters (e.g. scheduling information for 

secondary SI, RACH, PCH, E-MBMS etc.) 

- L1 information, example set of needed L1 parameters: 

Note: RAN1 needs to define what parameters are needed at this phase. 

- Carrier Bandwidth: FFS if separate bandwidths for UL and DL are needed; 

- Carrier center frequency (FFS); 

- Cyclic Prefix parameters: in order to decode DL-SCH UE needs to know the CP length arrangements; 

- MIMO related parameters: in order to take advantage of the multi-antenna transmissions like MIMO, the UE 

needs to know parameters of number of TX antennas, DL/UL pre-coding matrices, etc...; 

- Band Information: may be needed if the same DL carrier frequency has variable UL carrier frequency; 

- L1/L2 signalling channel structure parameters: if L1/L2 signalling channel has variable configurations, the 

UE may need to know its channel structure at least partly. L1/L2 signalling is crucial to receive any 

allocation information. If Random Access Response is transmitted without L1/L2 signalling (e.g. 

synchronous transmission with Random Access Preamble), this information might not be required; 

- RACH parameters (needed by the UE to start usage of RACH): 

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

Release 8 88 3GPP TS 36.300 V8.1.0 (2007-06)

- RACH scheduling information: UE needs to know where in time (sub-frame) and frequency (Physical 

Resource Units) the RACH channel is located; 

- RACH sequences: UE needs to know the RACH set of sequences to choose from. The sequences may not be 

fully of equal meaning (e.g. CQI can be classified for the sequences in a specific way); 

- Access class restrictions: access class restrictions might be needed to limit the number of possible UEs using 

RACH; 

- Persistence values: possible persistence value scheme parameters are needed for RACH usage; 

- Other parameters related to RACH: UE needs to know the timers and parameters related to RACH e.g. how 

often the UE retransmits RACH and how many times the retransmission is allowed etc; 

- RACH power control parameters: UE needs to know parameters related to UL power control. 

C.1.5 Information needed while camping on a cell 

When a UE has camped on a cell, it needs to continue measuring the neighbouring cells in order to stay camped. The 

pieces of information required for that are: 

- Measurement parameters: 

- In order for the UE to start mobility procedures, it needs to receive parameters e.g. of reporting periods, 

reporting event parameters, time to trigger etc. UEs in RRC_IDLE state need cell reselection parameters. 

UEs in RRC_CONNECTED state need parameters of the neighbour cells e.g. for handover and for error 

recovery cases. 

- Neighbour cell lists are needed to start neighbour cell measurements. UEs in different states may use 

different sets of neighbour cell lists. Neighbour cell list may contain following parameters: 

- Some L1 parameters: FFS what parameters are needed in the neighbour cell list; 

- All information that is needed for camping: see sub-clauses C.2.2 and C.2.3 (FFS); 

- Synchronization information: indicating whether the neighbouring cell is synchronized to the current cell 

i.e. the cell sending the neighbour cell list (FFS); 

- PLMN identity(ies) & tracking area identity (FFS); 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Other 3GPP RAT information: e.g. neighbour cell information of GERAN/UTRAN cells; 

- Information of non-3GPP access systems (e.g. WIMAX). 

- Secondary NAS parameters: 

- An y NAS parameters that were not presented earlier e.g. cell identity uniquely identifying cell within wide 

area e.g. PLMN; 

- Cell identity (PLMN level) (FFS if this should be in category “Information needed prior to cell access”). 

- Secondary UE timer values: any timer values that affect UE’s behaviour. 

- Paging parameters: UEs in LTE_IDLE state need to receive paging parameters e.g. DRX periods and scheduling. 

- Clock time (FFS): the network might send system clock in order to let UEs update their clock time e.g. in the 

user interface; 

- MBMS service parameters: any parameters needed for MBMS reception e.g. MBMS multiplexing parameters, 

MBMS frequency; 

NOTE: the presence of these parameters also indicate the presence of MBMS service in the cell (dedicated or 

mixed cell). 

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

Release 8 89 3GPP TS 36.300 V8.1.0 (2007-06)

- Signalling Radio Bearer parameters: may be broadcasted unless they are standardized. 

C.1.6 Thoughts about category division 

From UEs’ point of view the categories in sub-clauses C.1.2 and C.1.3 are very similar. Thus it is questionable whether 

we need to differentiate procedures between cell search/selection/camping and PLMN search. 

From UEs’ point of view, the difference between the procedure for cell search during RRC_CONNECTED and the 

procedure for cell search during RRC_IDLE state maybe small. When the UE is in RRC_CONNECTED state, it 

measures the neighbour cell and executes handovers commanded by the network. 

C.2 Division of SI between static and flexible parts 

System information distribution can be classified into two distinctive parts: static and flexible. Static part is sent more 

often, say once per frame, in the cell and has quite a limited capacity for information transfer. The flexible part has 

flexible amount of scheduled resources available and thus most of the SI information is contained there.

C.2.1 Static part 

The static parts of the System Information are: 

- L1 information in order to decode the rest of the information 

Note: detailed information on the required information will be defined by RAN1; 

- Measurement Cell identity (FFS): it may be possible that L1 channels do not identify the cell. Then some Cell 

identity needs to be sent on system information part; 

- Any cell access restriction parameters e.g.: 

- Tracking area identity: if forbidden TA concept is adopted from legacy systems then UEs need to know 

whether the cell belongs to forbidden TA; 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Cell barring and cell reservation status (FFS if needed per PLMN): UEs need to know whether cell is barred 

or reserved in order to avoid camping on barred cell. Possibly also barring time might be needed in order to 

avoid UEs to poll barring time frequently from the system information; 

- Radio access limitation parameters: any radio condition parameters that limit the access to the cell e.g. 

similar to GSM C1/S criteria; 

- PLMN identity(ies): in order to acquire information to which PLMN cell belongs, UEs need to receive 

PLMN identity(ies). 

NOTE: there may be multiple PLMN identities for one cell. 

- Scheduling parameters: 

- All of the scheduling information of flexible part or part of scheduling information (e.g. scheduling block) of 

flexible part. If static part consists of multiple SI blocks then it may be necessary to have scheduling 

information of those blocks in the static part. 

- Scheduling block defines, from where (time and frequency resources) to decode the SI blocks of the 

scheduled flexible part. It may be possible that scheduling of scheduling block is standardized, then this 

information can be omitted from the static part. If several types of scheduling blocks are defined , 

scheduling information might be sent for each scheduling block. 

- Value_tag(s): informs whether the information transmitted on the flexible part has changed. This is needed in 

order to avoid UEs from reading any unchanged information repeatedly. Another possibility is to send this 

information in L1/L2 signalling channel, but possibly it would cause too much overhead. 

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

Release 8 90 3GPP TS 36.300 V8.1.0 (2007-06)

NOTE: It also is possible to include Value_tag for SI on the flexible part indicating more precisely what changes 

have occurred in the system information. 

NOTE: There may be a need for indicating changes in static part with value tag also, if static part consists of 

multiple SI blocks. 

Table C.2.1 gives an estimate of the size of the elements mentioned above.

Table C.2.1: Initial rough estimates for static part capacity requirement 

Information element Bits 

Cyclic Prefix (FFS) 2 

Carrier BW (FFS) 3-8 

MIMO parameters (FFS) 2 (+ 3) 

Cell Id (FFS) 9 

Tracking Area Id (+ FFS how many additional) [16-28] 

Cell Barring status+ possible Time of barring 1+4 

Cell reservation status [2] 

Radio access limitation parameters 12 

PLMN id(s) maximum of 5 ( 24 bits per one) - see Note 120 

Scheduling parameters (12-108) 

Value Tag 4 

SFN (FFS) 11 

 

NOTE: It might not be necessary to send the Mobile Country Code part of the PLMN identity for each indicated 

PLMN to limit the number of bits. 

C.2.2 Flexible part 

The flexible part has different types of Information Elements which require independent scheduling in order to allow 

fast enough reception and not to waste transmission capacity. For example, the requirement to receive cell access 

parameters is very different than e.g. the clock time. Thus following flexible part division should be considered: 

- Scheduling block: scheduling information of the secondary part of the System Information. 

- Access parameters: 

- All parameters not present in the primary part (e.g. some L1 parameters); 

- RACH parameters; 

- Power control parameters; 

- Paging parameters; 

- Any timer values needed for operating in the cell and in the network. 

- Measurement related parameters: 

- Neighbour cell lists; 

- Cell selection/reselection parameters; 

NOTE: Some of these parameters are included in the static part element “Radio access limitation parameters.” 

- Measurement control information; 

- Non vital information: 

- Clock time; 

- Positioning (A-GNSS etc.) information; 

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

Release 8 91 3GPP TS 36.300 V8.1.0 (2007-06)

- Service parameters (e.g. MBMS parameters); 

- Secondary NAS parameters. 

C.2.3 Information whose location is FFS 

The location of the following information is FFS: 

- System Frame Number: SFN might be needed very fast i.e. for HO purposes. SFN might be needed also for 

decoding scheduling block parameters, but on the other hand it might be requested not to send often changing 

information on the static part in order to be able to make time soft combining. Further investigation on the SFN 

broadcasting is thus needed. 

C.2.4 Dedicated part 

The dedicated part is embedded in the RRC message that is meant for sending System Information Elements in unicast 

mode e.g. for HO purposes, positioning purposes .... The UE needs some information for the neighbouring cell to 

access it, this is needed to limit the interruption times caused by HO execution. When a UE receives a HO COMMAND 

it needs at least following information from the target cell: 

- All information in the static part (see sub-clause C.2.1): may be received by the UE by itself; 

- Most of the information from the access parameters (see sub-clause C.2.2): is favourably delivered by dedicated 

manner via the source cell, because the UE might not have time to get all the necessary secondary SI from the 

target cell; 

- System Frame Number is needed to minimize the interruption times during the HO procedure. Most probably the 

UE needs to receive (at least confirm) the SFN directly by the neighbour cell SI reading, because giving the SFN 

via source cell may cause some inaccuracy to the SFN. 

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

Release 8 92 3GPP TS 36.300 V8.1.0 (2007-06)

Annex D (informative): 

MBMS 

D.1 MBMS control & functions 

The E-UTRAN supporting MBMS comprises eNBs and co-ordinating functions. 

The functions hosted by the eNB may be: 

- Scheduling and transmission of MBMS control information; 

- Scheduling of single-cell MBMS transmissions; 

- Transmission of single-cell and multi-cell MBMS services; 

- Radio bearer control for MBMS. 

The co-ordinating functions may include: 

- Distribution of MBMS services; 

- Co-ordination of multi-cell MBMS transmissions; 

- MBMS SAE bearer control. 

It is FFS which node in E-UTRAN performs the co-ordination functions. 

D.2 MBMS transmission 

A point-to-multipoint radio bearer is used to carry MBMS traffic. It is FFS whether a point-to-point radio bearer is also 

used to carry MBMS traffic or not. Improvements for single-cell MBMS transmission (e.g. HARQ) and MCS that 

would enable potential removal of p-t-p transmissions for MBMS are FFS. 

A frequency layer can be dedicated to MBMS transmissions: 

- When a cell belongs to a frequency layer dedicated to MBMS transmissions (MBMS-dedicated cell): 

- The MBMS transmission (MTCH and MCCH) occurs on MCH or DL-SCH (FFS); 

- No uplink or counting mechanism supported; 

- No support for unicast data transfer in the cell; 

- The occurrence of paging messages on the frequency layer dedicated to MBMS transmission is FFS: 

- If paging messages were allowed, the UE could answer in a non-E-UTRA cell e.g. UTRA cell (FFS); 

- The possible multi-cell p-t-m transmission with SFN operation on the MCH of the SFN area is semi-statically 

configured e.g. by O&M. 

- Single-cell p-t-m transmission is possible. 

- When a cell does not belong to a frequency layer dedicated to MBMS transmissions (MBMS/Unicast-mixed 

cell): 

- Transmission of both unicast and MBMS transmissions in the cell is done in a co-ordinated manner on DLSCH and or MCH+DL-SCH (FFS); 

- The possible SFN operation on the MCH of the SFN area is semi-statically configured e.g. by O&M; or the 

SFN area is dynamic and may be based on counting mechanisms (FFS). 

- Counting is possible (FFS); 

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

Release 8 93 3GPP TS 36.300 V8.1.0 (2007-06)

- P-t-p transmission on DL-SCH is FFS. 

There are two types of MBMS transmissions in E-UTRA/E-UTRAN: 

a) Single-cell transmission (no SFN operation): 

- The MBMS service, e.g. message distribution, is transmitted only on the coverage of a specific cell; 

- The MBMS service (MTCH and MCCH) may be transmitted on DL-SCH or MCH (FFS); 

- Combining of MBMS transmission from multiple cells is not supported; 

- Counting for switching between p-t-p and p-t-m radio bearer may be supported (FFS); 

- The p-t-m/p-t-p switching points are either dynamically decided based on counting mechanism or semistatically configured by O&M (FFS). 

b) Multi-cell transmission (SFN operation): 

- The MBMS service (MTCH and MCCH) is transmitted on MCH; 

- Combining is supported with SFN; 

- Synchronous transmission. 

The BCCH indicates where the MCCH(s) are: 

- One (or none) MCCH per cell for cell specific transmission; 

- MCCH(s) sent in SFN area for non-cell specific transmission. 

Having a feedback mechanism for MTCH transmission is FFS: statistical feedback, TTI based NACK or something 

else. Also is FFS if the re-transmission is a single cell transmission in all cases. 

D.3 Deployment Scenarios 

In terms of deployment scenarios of MBMS in E-UTRAN, the following alternatives can be listed: 

- Carrier type: dedicated vs. mixed carrier; 

- SFN transmission: multi-cell vs. single-cell transmission; 

- Radio bearer type: p-t-m vs. p-t-p; 

- Counting: yes or no; 

- Audience measurement: yes or no; 

- ON/OFF control of MBMS service delivery: yes or no; 

- PTP / PTM radio bearer switching: yes or no; 

Table D.3 below lists the combinations of the above alternatives that are supported in E-UTRAN: 

Table D.3: MBMS Deployment Scenarios 

# Carrier Transmission RB Counting Comments 

1 dedicated multi-cell p-t-m no From 1 to n cells 

Audience measurement (FFS) 

2 mixed multi-cell p-t-m no Audience measurement (FFS) 

... ... ... ... ... ... 

Note: other deployment scenarios will be included once agreed. 

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

Release 8 94 3GPP TS 36.300 V8.1.0 (2007-06)

Annex E (informative): 

Drivers for Mobility Control 

Table E.1 lists the drivers, limitations, and their applicability to intra-frequency, inter-frequency, and inter-RAT 

scenarios. Each driver and limitation is described in Section E.1 and E.2, respectively. For inter-frequency and interRAT scenarios, the applicable drivers are shown in detail for IDLE/ACTIVE modes and their transitions in Section E.3. 

Table E.1: Drivers and limitations for mobility control and applicability to mobility scenarios. 

# Drivers/limitations Intrafrequency Interfrequency Inter-RAT 

Drivers 1 Best radio condition X X X 

2 Camp load balancing X X 

3 Traffic load balancing X X 

4 UE capability X X 

5 Hierarchical cell structures X X 

6 Network sharing X X 

7 Private neworks/home cells X X 

8 Subscription based mobility control X X 

9 Service based mobility control X X 

10 MBMS X X 

Limitations 11 UE battery saving X X X 

12 Network signalling/processing load X X X 

13 U-plane interruption and data loss X X X 

14 OAM complexity X X X 

As shown in Table E.1, the applicable drivers depend on the mobility scenario, i.e., intra-frequency, inter-frequency, 

and inter-RAT: 

- Intra-frequency mobility: intra-frequency mobility is the most fundamental, indispensable, and frequent 

scenario. With the frequency reuse being one in E-UTRAN, applying any driver other than the “best radio 

condition” to intra-frequency mobility control incur increased interference and hence degraded performance. As 

such, only the “best radio condition” driver is applicable to intra-frequency mobility. Note that the exact 

definition of “intra-frequency mobility” is yet unclear, and shall be clarified with RAN1. 

- Inter-frequency mobility: as in UTRAN, an operator may have multiple carriers/bands for E-UTRAN working 

in parallel. The use of these frequency layers may be diverse. For example, some of these frequency layers may 

utilise the same eNB sites and antenna locations (i.e., co-located configuration), whereas some may be used to 

form a hierarchical cell structure (HCS), or even be used for private networks. Some frequency layers may 

provide MBMS services, while some may not. Moreover, E-UTRAN carriers/bands may be extended in the 

future to increase capacity. For example, as E-UTRAN gains popularity, an operator may decide to convert 

existing UTRAN carriers into E-UTRAN ones. The operator may also acquire additional carriers/bands, that are 

not necessarily contiguous. As a consequence, different UE band capabilities may coexist and different 

carriers/bands may operate at different areas within a network. The E-UTRAN standard should readily support 

such carrier/band extensions and diverse network configurations, providing flexibility and efficiency. Therefore, 

a number of drivers apply to inter-frequency mobility control, in addition to the “best radio condition” driver. 

- Inter-RAT mobility: the aspects that need to be considered for inter-RAT are similar to those for interfrequency. For mobility solutions to be complete with the inter-RAT drivers, relevant updates would be 

necessary on the legacy (UTRAN/GERAN) specifications. This will add to the limitations, which are evidently 

more effective in inter-RAT. Although the drivers/limitations need to be assessed per objective RAT 

(UTRAN/GERAN), the solutions should be made common as much as possible to reduce any complexity. 

E.1 Drivers 

The drivers for mobility control are described in the following sections. 

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

Release 8 95 3GPP TS 36.300 V8.1.0 (2007-06)

E.1.1 Best radio condition 

The primary purpose of cell reselection, regardless of intra-frequency, inter-frequency, or inter-RAT, is to ensure that 

the UE camps on/connects to the best cell in terms of radio condition, e.g., path loss, received reference symbol power, 

or received reference symbol Es/I0. The UE should support measurements to suffice this aspect. For E-UTRAN cells, 

the frequency domain scheduling and channel/symbol mapping may have some implications to designing the 

measurements and reselection/reporting criteria. The UE would also have to check that the selected cell falls within the 

accesible range (in terms of signal strength and possibly also in terms of propagation delay, i.e., check if it falls within 

the dynamic range of timing advance, FFS). 

E-UTRAN should support good mobility even when the radio environment changes suddenly, e.g., when the UE enters 

a tunnel or in a Manhattan-like street cell scenario. It should be discussed whether a special mechanism is needed to 

cope with such sudden changes in radio environment or it can be handled with good radio network planning practices. 

In either case, the system design should minimise any side effects of counteracting the sudden changes in the radio 

environment (e.g., ping-pongs). 

For inter-frequency/RAT mobility, the UE needs idle gaps to perform measurements on other frequency layers/RATs. 

In addition, for inter-RAT, E-UTRAN measurements while the UE is in another RAT (UTRAN/GERAN) need to be 

supported. It should be discussed whether in certain cases (e.g., co-located E-UTRAN cells within the same frequency 

band) the measurements can be omitted. 

E.1.2 Camp load balancing 

This is to distribute idle state UEs among the available bands/carriers/RATs, such that upon activation, the traffic 

loading of the bands/carriers/RATs would be balanced. At least the path loss difference between different bands should 

be compensated to avoid UEs concentrating to a certain frequency layer (e.g., lower frequency bands due to the 

propagation nature). A deliberate mechanism would be necessary to avoid UEs concentrating to a certain RAT (e.g., EUTRAN). Various solutions have been presented including the use of Qoffset and an approach of limiting the frequency 

layers for camping. 

For inter-RAT, this driver also includes the aspect of balancing the loading of core network nodes of different RATs. 

Nevertheless, for intra- E-UTRAN, the core network load aspect is out of scope, since MME/Serving Gateway 

relocation by itself should not cause any radio mobility procedure (but only NAS procedures like NAS ID and security 

updates). 

E.1.3 Traffic load balancing 

This is to balance the loading of active state UEs, using redirection for example. In E-UTRAN, traffic load balancing is 

essential because of the shared channel nature. That is, the user throughput decreases as the number of active UEs in the 

cell increases, and the loading directly impacts on the user perception. A solution is desired that causes minimum 

impact on the user perception. This implies that inter-layer transitions are preferably done during data inactivity (e.g., 

DRX) or transition to the idle state. Although this driver is also applicable to inter-RAT, for inter-RAT, the “service 

dependent control” driver may be more dominant than the load balancing aspect. 

E.1.4 UE capability 

As E-UTRAN bands/carriers may be extended in the future, UEs having different band capabilities may coexist within 

a network. It is also likely that roaming UEs have different band capabilities. Overlaying different RATs adds to this 

variety. The mobility solution should cope with the coexistence of various UE capabilities in an efficient manner. 

E.1.5 Hierarchical cell structures 

As in UTRAN, hierarchical cell structures (HCS) may be utilised in E-UTRAN to cover for example, indoors and hot 

spots efficiently. It is possible that E-UTRAN is initially deployed only at hot spots, in which case this driver becomes 

essential for inter-RAT, not just for inter-frequency. Another use case would be to deploy a large umbrella cell to cover 

a vast area without having to deploy a number of regular cells, while providing capacity by the regular cells on another 

frequency. While HCS can be seen as a solution to reduce measurement and signalling loads, to optimise HCS usage, 

mobility control should take into account the UE mobility (e.g., speed). This however implies that sufficient mobility 

detection is also required. Although HCS is not addressed as a mobility driver for intra-frequency mobility, intrafrequency HCS deployment should not be restricted. 

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

Release 8 96 3GPP TS 36.300 V8.1.0 (2007-06)

E.1.6 Network sharing 

At the edge of a shared portion of a network, it will be necessary to direct UEs belonging to different PLMNs to 

different target cells. The mobility solutions in both idle and active states should therefore support differentiation 

between UEs of different operators. 

E.1.7 Private networks/home cells 

Cells that are part of a sub-network should prioritise the camping on that sub-network. UEs that do not belong to private 

sub-networks should not attempt to camp or access them. Although this could be resolved by the use of forbidden TAs 

as in UTRAN, a more deliberate mechanism may be needed as some of these sub-networks could be very small, e.g., 

one home. 

E.1.8 Subscription based mobility control 

This mobility driver aims to limit the inter-RAT mobility for certain UEs, e.g., based on subscription or other operator 

policies. The system should provide means to dissallow access on certain RATs (including E-UTRAN) as done with 

"LA reject" in legacy systems. It should be possible for the operator to trigger a subsequent UE action such as a cell or 

PLMN selection. 

E.1.9 Service based mobility control 

An operator may have different policies in allocating frequencies to certain services. For example, the operator may 

concentrate VoIP UEs to a certain frequency layer or RAT (e.g., UTRAN or GERAN), if evaluations prove this 

effective. UEs requiring higher data rates may better be served on a frequency layer or RAT (e.g., E-UTRAN) having a 

larger bandwidth. The operator may also want to accommodate premium services on a certain frequency layer or RAT, 

that has better coverage or larger bandwidth. 

This driver is essential for inter-RAT, due to the different QoS levels provided by different RATs. The nature of the 

service being requested (e.g., QoS and traffic behaviour) should be considered in controlling mobility, so that services 

are accommodated in the best suitable RAT. Note that such service dependent control shall only be based on network 

decisions and not on UE decisions (i.e., no UE based service dependent cell reselection), except for MBMS scenarios. 

E.1.10 MBMS 

As MBMS services may be provided only in certain frequency layers, it may be beneficial/necessary to control interfrequency/RAT mobility depending on whether the UE receives a particular MBMS service or not. For MBMS 

scenarios only, UE based service dependent cell reselection might be considered acceptable. This aspect also depends 

on the UE capability for simultaneous reception of MBMS and unicast. 

E.2 Limitations for mobility control 

While the issues mentioned above drive E-UTRAN towards “aggressive” mobility control, the limiting factors also 

have to be considered. The factors listed below apply to all intra-frequency, inter-frequency, and inter-RAT mobility 

scenarios. 

E.2.1 UE battery saving 

The mobility solution should not consume excessive UE battery, e.g., due to measurements, measurement reporting, 

BCH reception, or TA update signalling. This could be achieved for example by setting appropriate measurement rules 

such as S-criteria, hysteresis, and time-to-trigger. Adaptive control of some measurement/mobility parameters (e.g., 

based on DRX, cell size, or mobility) may also be considered as a countermeasure. To reduce TA update signalling, TA 

allocations can be differentiated depending on the UE speed or the mobility vector, on top of appropriate TA planning. 

Effects on additional delays (e.g., paging) should also be investigated if means such as “long DRX” are used to achieve 

these savings. 

It should be investigated together with RAN4 if a coupling between measurements accuracy and DRX (as in UTRAN) 

is also acceptable for E-UTRAN. 

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

Release 8 97 3GPP TS 36.300 V8.1.0 (2007-06)

E.2.2 Network signalling/processing load 

The mobility solution should not cause excessive network signalling/processing load. This includes over-the-air 

signalling, S1/X2 signalling, and processing load at network nodes. Unnecessary handovers and cell reselections should 

be avoided, and PCH and BCH signallings, as well as dedicated signallings, should be limited. This could be achieved 

by similar countermeasures as for UE battery saving. 

E.2.3 U-plane interruption and data loss 

U-plane interruption and data loss caused by the mobility solution should be limited. The required QoS should be 

satisfied in any case. 

E.2.4 OAM complexity 

The mobility solution should not demand excessive efforts in operating/maintaining a network. For example, when a 

new eNB is added or an existing eNB fails, the mobility solution should not incur excessive efforts to set up or modify 

the parameters. Means should be studied to integrate the mobility solutions in the concept of “self-optimisation” to 

minimise manual processes. Reducing the neighbour list information in E-UTRAN would also be a countermeasure to 

this requirement. 

E.3 Inter-frequency/RAT drivers 

E.3.1 Mobility control during IDLE mode 

This is to control the mobility of UEs during IDLE mode, i.e., cell reselection. Table E.3.1-1 summarises applicability 

of the drivers for different inter-frequency/RAT scenarios and necessary features to support the drivers. Note that in 

Tables E.2-E.5, an “X” in the table indicates that the driver is essential, whereas an "(X)" indicates that the driver may 

be reduced in support depending on the complexity incurred. Furthermore in Tables E.3.1-1-, E.3.2-1, E.3.3-1, E.3.4-1, 

the following abbreviations are used: 

- LL: LTE to LTE inter-frequency mobility; 

- LU: LTE to UTRAN inter-RAT mobility; 

- UL: UTRAN to LTE inter-RAT mobility; 

- LG: LTE to GERAN inter-RAT mobility; 

- GL: GERAN to LTE inter-RAT mobility. 

Table E.3.1-1: Mobility control during IDLE (cell reselection). 

# 

Drivers 

Applicability 

Necessary features to support drivers LL LU UL LG GL 

1 Radio condition X X X X X Inter-frequency/RAT measurements (solutions to 

mitigate measurement load should be 

considered, e.g., S-criteria); 

Cell reselection and reselection criteria. 

2 Camp load 

balancing 

X X X (X) (X) Mechanism to prioritise cell reselection to certain 

layer/RAT, depending on the loading of 

layers/RATs; 

Load information exchange (not needed if 

balancing is inadaptive, i.e., only based on 

subscriber penetration on each band/RAT.). 

3 Traffic load 

balancing 

N/A 

4 UE capability (X) X X X X Mechanism to prioritise cell reselection to certain 

layer/RAT, depending on the UE capability. 

5 HCS (X) (X) (X) (X) (X) Mobility detection (e.g., number of crossed 

cells); 

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

Release 8 98 3GPP TS 36.300 V8.1.0 (2007-06)

Mechanism to prioritise cell reselection to certain 

layer/RAT, depending on the UE speed (e.g., 

HCS mechanism as in UTRAN). 

6 Network sharing X X X X (X) Mechanism to direct the UE to the appropriate 

PLMN at a network sharing border; 

Mechanism to restrict UE measurements and 

reselection to cells that are entitled to access. 

7 Private neworks 

/ home cells 

X (X) X (X) Mechanism to prioritise reselection to 

private/home cells that are entitled to access; 

Mechanism to restrict UE measurements and 

reselection to cells that are entitled to access; 

Other unidentified features, FFS. 

8 Subscription / 

Policy based 

mobility control 

X X X (X) (X) Mechanism to prioritise cell reselection to certain 

layer/RAT, depending on the subscription 

information or any other operator policy (e.g., for 

LL there may be cases where an operator has 

policy in allocating UEs to certain frequencies 

due to different carrier bandwidths). 

9 Service based 

mobility control 

N/A 

10 MBMS X (X) X Mechanism to prioritise cell reselection to the 

layer/RAT, depending on whether the UE 

requires reception of a certain MBMS 

transmission. 

E.3.2 Mobility control upon IDLE to ACTIVE transition 

This is to control the mobility of UEs upon IDLE to ACTIVE transition, i.e., redirection upon RRC or U-plane 

establishment. Table E.3.2-1 summarises applicability of the drivers for different inter-frequency/RAT scenarios and 

necessary features to support the drivers. 

Table E.3.2-1: Mobility control upon IDLE to ACTIVE transition 

(redirection upon RRC/U-plane establishment) 

# Drivers 

Applicability 

Necessary features to support drivers LL LU UL LG GL 

1 Radio condition (X) (X) Inter-frequency/RAT measurements (during 

IDLE mode or upon IDLE to ACTIVE transition) 

and measurement reporting upon RRC 

establishment (it should be investigated whether 

measurements can be omitted in some or all 

cases, e.g., co-located cells). 

2 Camp load 

balancing 

N/A 

3 Traffic load 

balancing 

X (X) (X) (X) Redirection to a certain layer/RAT (cell) upon 

RRC establishment, depending on the loading of 

layers/RATs; 

Load information exchange (not needed if 

balancing is inadaptive, i.e., only based on 

subscriber penetration on each band/RAT). 

4 UE capability X (X) (X) Redirection to a certain layer/RAT (cell) upon 

RRC establishment, depending on the UE 

capability. 

5 HCS N/A 

6 Network sharing (X) (X) (X) (X) Redirection to a certain layer/RAT (cell) of the 

preferred PLMN, upon RRC establishment. 

7 Private neworks 

/ home cells 

(X) Redirection from a certain private/home cell. 

8 Subscription / 

Policy based 

mobility control 

X X (X) (X) (X) Redirection to a certain layer/RAT (cell) upon 

RRC establishment, depending on the 

subscription information (if available upon 

establishment) or any other operator policy. 

9 Service based 

mobility control 

X X (X) (X) (X) Redirection to a certain layer/RAT (cell) upon 

RRC establishment, depending on the requested 

service (if the service information is available 

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

Release 8 99 3GPP TS 36.300 V8.1.0 (2007-06)

upon establishment). 

10 MBMS N/A 

E.3.3 Mobility control during ACTIVE mode 

This is to control the mobility of UEs during ACTIVE mode (LTE_ACTIVE or UTRAN RRC Connected), i.e., 

handover. Table E.3.3-1 summarises applicability of the drivers for different inter-frequency/RAT scenarios and 

necessary features to support the drivers. 

Table E.3.3-1: Mobility control during ACTIVE (handover) 

# Drivers 

Applicability 

Necessary features to support drivers LL LU UL LG GL 

1 Radio condition X X X X (X) Gap assisted inter-frequency/RAT 

measurements (network controlled); 

Measurement reporting and reporting criteria; 

Inter-frequency/RAT handover (UE assisted 

network controlled). 

2 Camp load 

balancing 

N/A 

3 Traffic load 

balancing 

X (X) (X) (X) Inter-frequency/RAT handover (network 

controlled); 

Load information exchange (not needed if 

balancing is inadaptive, i.e., only based on 

subscriber penetration on each band/RAT). 

4 UE capability (X) (X) (X) (X) Inter-frequency/RAT handover (network 

controlled), depending on the UE capability. 

5 HCS (X) (X) (X) Mobility detection (e.g., number of crossed 

cells); 

Inter-frequency/RAT handover (network 

controlled), depending on the UE speed. 

6 Network sharing X X X X Inter-frequency/RAT handover (network 

controlled) to a cell of the appropriate PLMN at 

network sharing border; 

Mechanism to restrict UE measurements to cells 

that are entitled to access. 

7 Private neworks 

/ home cells 

X X X X X Inter-frequency/RAT handover (network 

controlled) to a private/home cell on another 

layer/RAT, where the UE is entitled to access; 

Mechanism to restrict UE measurements and 

reselection to cells that are entitled to access; 

Other unidentified features, FFS. 

8 Subscription / 

Policy based 

mobility control 

(X) X X X X Inter-frequency/RAT handover (network 

controlled), depending on the subscription 

information or any other operator policy. 

9 Service based 

mobility control 

(X) X X X X Inter-frequency/RAT handover (network 

controlled), depending on the service or 

combination of services being used or 

requested. 

10 MBMS X X X Inter-frequency/RAT handover (network 

controlled), depending on whether the UE 

requires reception of a certain MBMS 

transmission. 

E.3.4 Mobility control upon ACTIVE to IDLE transition 

This is to control the mobility of UEs upon ACTIVE to IDLE transition, i.e., redirection upon RRC or U-plane release. 

Table E.3.4-1 summarises applicability of the drivers for different inter-frequency/RAT scenarios and necessary 

features to support the drivers. 

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

Release 8 100 3GPP TS 36.300 V8.1.0 (2007-06)

Table E.3.4-1: Mobility control upon ACTIVE to IDLE transition (redirection upon RRC/U-plane 

release) 

# Drivers 

Applicability 

Necessary features to support the driver LL LU UL LG GL 

1 Radio condition X X X X X Gap assisted inter-frequency/RAT 

measurements (it should be investigated 

whether measurements can be omitted in some 

or all cases, e.g., co-located cells), OR 

Cell search upon redirection. 

2 Camp load 

balancing 

X X X (X) (X) Redirection to a certain layer/RAT upon RRC 

release, depending on the loading of 

layers/RATs; 

Load information exchange (not needed if 

balancing is inadaptive, i.e., only based on 

subscriber penetration on each band/RAT). 

3 Traffic load 

balancing 

N/A 

4 UE capability X X X (X) (X) Redirection to a certain layer/RAT upon RRC 

release, depending on the UE capability. 

5 HCS N/A 

6 Network sharing X X X X Redirection to a certain layer/RAT of the 

preferred PLMN, upon RRC release. 

7 Private neworks 

/ home cells 

N/A 

8 Subscription / 

Policy based 

mobility control 

X X X (X) (X) Redirection to a certain layer/RAT upon RRC 

release, depending on the subscription 

information or any other operator policy. 

9 Service based 

mobility control 

(X) (X) (X) Redirection (or maintaining) to a certain 

layer/RAT upon RRC release, depending on the 

service that has been used (predicting that the 

UE uses the same service in the future). 

10 MBMS (X) (X) (X) Redirection to a certain layer/RAT upon stop of 

an MBMS service reception. 

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

Release 8 101 3GPP TS 36.300 V8.1.0 (2007-06)

Annex F (informative): 

Mobility and Access Control Requirements associated with 

Closed Subscriber Group (CSG) Cells 

F.1 Access Control 

The following description is provided from the perspective of the Home cell deployment, and is used as an example to 

understand the general requirements of Closed Subscriber Group (CSG) Cells. 

If an operator uses the 2G or 3G systems for a deployment in a home, there are some limitations imposed by mandating 

that only a UE from a specific User Group can access the cell. This access restriction is needed because some backhaul 

links for this type of deployment are not considered to provide adequate QoS to support a large numbers of UEs, or 

there may be regulatory issues with sharing the backhaul link/eNB access in that location, and additionally the backhaul 

maybe owned by the subscriber and they may not be happy to share the link with other subscribers. 

In 3G, the Access Control would work based on the Location Updating or Routing Area Updating Reject for the LA or 

RA which is being signalled on the cell. Each unique User Group would require its Location Area ID, however the LAC 

of the LA ID is only 2 octets, which needs to be shared with the normal LAs of the PLMN. 

There is an additional drawback with this solution in 3G, which is that all terminals would attempt to perform the 

Location Updating procedure on a cell advertising a LA not on the list of forbidden LAs in the UE. The network would 

reject the location updating procedure of those UEs which are not in the User Group associated with the LA. This would 

lead to the scenario in a densely populated area, where a UE moving down the street could attempt to access a home cell 

at each house, before being rejected causing a wastage of battery in the terminal, and unnecessary signalling/processing 

load in the core network. 

1. A UE should not camp on or access a CSG Cell if it is not part of the User Group which is allowed to 

access that CSG Cell. 

The User Group associated with a specific Home-eNB needs to be updated, under the supervision of the network 

operator, by the the subscriber which is registered as the owner of the Home-eNB. When a subscriber is added to the 

User Group by the registered owner of the Home-eNB, the UE of the subscriber should be able to (almost) immediately 

camp on the cell(s) of Home-eNB and then may acquire service through the Home-eNB. This is especially important in 

the deployment scenario where this subscriber has no other means to access the network, i.e. there is no Macro-layer 

coverage available. 

2. The subscriber registered as the owner of a CSG Cell or group of Cells, under supervision of the operator, 

shall be able to control/modify quickly which other subscribers form part of the User Group associated 

with its CSG Cell(s). 

F.2 Mobility 

The Home-eNB/CSG cells should form part of the network of the operator, and therefore the design needs to support 

mobility of UEs between the Macro-Layer network and the Home-eNB/CSG cells. In the following text, what is called 

Macro layer encompasses all the cells which are not from the CSG being considered i.e. it is not about their 

size/coverage but the fact that they are not closed. 

3. The system shall support handover between CSG Cells and any eNodeB (E-UTRAN) or RNC (UTRAN) or 

BSS (GERAN) or with another CSG Cell of the same or different CSG. 

The Home-eNBs will be deployed to improve network coverage, improve network capacity as well as offer differential 

billing models. As the User billing could be dependent on whether the UE is using the Home-eNB, it is important that 

the UE when it is range of the Home-eNB automatically camps on the Home-eNB. 

4. It shall be possible to set the reselection parameters, for UEs which are allowed to access the cell, such that 

they prioritise the CSG Cells for camping when in coverage of the cells. 

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

Release 8 102 3GPP TS 36.300 V8.1.0 (2007-06)

It is important that UEs camped on the Home-eNB do not cause excessive signalling load or processing load if/when the 

UE moves frequently between the Macro-Layer network and the Home-eNB. 

5. The system shall avoid excessive signalling and processing load from a UE frequently reselecting in LTE 

Idle between the CSG Cells and the non-CSG cells of eNodeB (E-UTRAN) or RNC (UTRAN) or BSS 

(GERAN). 

As discussed above, the Home-eNBs will have an associated User Group describing which UEs can access the HomeeNB. The handover procedures needs to take the User Group of the Target Home-eNB into account when deciding 

whether to handover a UE to a specific Home-eNB. The solution for the mobility to/from the Home-eNB should avoid 

unnecessary signalling between the RAN nodes. 

6. The handover procedures shall take into account whether a UE is part of the User Group of the target 

CSG Cell. The mobility procedures should allow for prioritisation of the CSG Cells in LTE_ACTIVE 

when the UE enters coverage of a CSG Cell and the UE is part of the User Group of this cell. 

As the number of Home-eNBs in the network will become large, the proportion of measurements made by a UE which 

could be wasted may become large, to the point where it affects the mobility performance of the UE/system, as well as 

draining the battery of the UE. It is therefore necessary for the UE to be able to avoid unnecessary measurements of 

Home-eNBs where the UE does not belong to the User Group of the Home-eNB. 

7. It shall be possible to minimise the quantity of measurements which UEs perform on CSG Cells, if the UE 

does not belong to the User Group of a specificCSG Cell. 

Due to the high number of Home-eNBs and the nature of their deployment, it would not be practical to change the 

configuration for the mobility procedures (measurements, handover, etc.) in the macro layer nodes when a Home-eNB 

is deployed/dismissed. 

8. The mobility procedures shall allow a large number of (small) CSG Cells to be deployed within the 

coverage of e-UTRAN, UTRAN and GERAN macro-layer cells. Deployment of (additional) CSG Cells 

shall not require reconfiguration of other eNodeB (E-UTRAN) or RNC (UTRAN) or BSS (GERAN). 

Annex G (informative): 

Guideline for E-UTRAN UE capabilities 

Each radio access technology has defined specific “classes” of terminals in terms of radio capabilities. E.g. in GPRS the 

“multislot classes” are defined, in UMTS R’99 different dedicated bearer classes are defined and for HSDPA and 

HSUPA 12 respectively 6 physical layer categories are defined. The definition of UMTS R’99 UE classes lead to 7 DL 

classes and 7 UL classes for FDD out of which only 2 DL and 3 UL classes were commercially realized. Furthermore 

the lower end classes (e.g. 64 UL and 64 DL) disappeared from the market with commercialization of the UMTS 

networks quite soon. Besides these class definitions a huge number of possible parameter combinations (to achieve 

certain data rates) exist with UMTS R’99 which lead to the huge number of RAB and RB combinations defined. Further 

activities in the early phase of UMTS standardization aimed to reduce the number of possible combinations 

significantly. 

For HSDPA two “simple” DL categories (11 & 12) with lowered complexity were defined with the intend to speed up 

commercialization of HSDPA. Originally those categories should have been removed for Rel-6. Out of the 12 defined 

categories only approx. 4 will be realized in commercial HSDPA platform products. A similar situation is likely for 

HSUPA as well as for the combinations of HSDPA/HSUPA. 

Generally the aim to mandate certain essential functions/requirements can help to simplify the system definition as well 

as the realization options (e.g. mandating 20 MHz of DL reception as well as 20 MHz UL transmission bandwidth 

significantly reduced the E-UTRAN system complexity). Especially mandating certain terminal functions could be 

useful for the system design if a defined subset of parameter combinations are also supported by the systems, e.g. the 

eNB scheduler. However, there is also a risk that not all the defined E-UTRA features are deployed in the networks at 

the time when terminals are made commercially available on the market place. Some features are likely to be rather 

large and complex, which further increases the risk of interoperability problems unless these features have undergone 

sufficient interoperability testing (IOT) on real network equipment, and preferably with more than one network in order 

to improve the confidence of the UE implementation. Thus, avoiding unnecessary UE mandatory features but instead 

defining a limited set of UE radio classes allows simplification for the interoperability testing. 

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

Release 8 103 3GPP TS 36.300 V8.1.0 (2007-06)

Given the discussion above, it seems beneficial for the introduction of E-UTRAN to limit the combination of radio 

capabilities to a clearly defined subset and ensure that a given set of parameters is supported by certain UE classes as 

well as networks for rapid E-UTRAN deployment. It seems unrealistic to mandate only one single UE class which 

always mandates the maximum capability. 

In order to address the different market requirements (low end, medium and high end), the definition of the following 

UE classes are proposed: 

Table G-1: E-UTRAN UE Classes 

Class UL DL 

A [50] Mbps [100] Mbps 

B [25] Mbps [50] Mbps 

C [2] Mbps [2] Mbps 

NOTE: For simplification reasons, the table only depict the UE capabilities in terms of uplink and downlink peak 

data rates supported. However, it should be noted that further discussion on other features is expected 

once the work progresses. 

It may require further discussion whether there be a need for an additional terminal class between 2 Mbps and 50 Mbps 

classes. It might make sense, since up to 5 MHz band allocations may be rather common in real deployments for several 

years. This would point to bit rate class of 25 Mbps in DL and 10 Mbps in UL. 

The above given data rates are indicative and should be subject for further discussions in 3GPP RAN working groups. 

Depending on the different solutions to reach those data rates, the target should be to define [3..4] UE classes in 

different data rate ranges, and other parameters affecting device complexity and cost. The definition of the required 

parameters/features is for further study for each of the classes. For instance, half-duplex UEs form a specific category 

that may be frequency band specific. 

NOTE: the support of half-duplex UEs is mandatory for the eNB where such a category is allowed in the 

frequency band supported by the eNB. 

The aim is to ensure on the one hand that high end E-UTRAN UEs, supporting data rates representing state of the art 

level and competitive with other radio technologies are defined, while the medium and lower data rates aim to reduce 

implementation cost for chipset/terminal vendors and allow adoption of most cost efficient solutions for different 

market segments. It is expected that the support of the high end data rate terminals is ensured from the very beginning. 

Another clear exception from this exercise is that on the low end very cheap product implementation is possible (e.g. for 

the machine-to-machine market or the voice and very low data rate only segment – to substitute GSM in the medium 

term) while top end performance is needed for data applications in notebooks, wireless gateways (“wireless DSL”), etc. 

Another important aspect that must be ensured is that a higher capability UE can be treated in exactly the same way as 

for a lower capability UE, if the network wishes to do so, e.g., in case the network does not support some higher 

capability features. In HSDPA, there has been problems in this respect due to 2-stage rate matching in HARQ. Such 

problems should be avoided in E-UTRAN, and E-UTRAN UE capabilities should provide the compatibility to ease 

implementation and interoperability testing. 

Annex H (informative): 

L1/L2 Control Signalling Performance 

The target quality on L1/L2 control channels of E-UTRAN is summarized in the two tables below: 

Table H-1: DL control signalling 

Event Target quality 

DL scheduling information miss detection (10-2) 

UL scheduling grant miss detection (10-2) 

NACK to ACK error (for UL-SCH) (10-4 – 10-3) 

ACK to NACK error (for UL-SCH) (10-4 – 10-3) 

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

Release 8 104 3GPP TS 36.300 V8.1.0 (2007-06)

Table H-2: UL control signalling 

Event Target quality 

ACK miss detection (for DL-SCH) (10-2) 

DTX to ACK error (for DL-SCH) (10-2 – 10-1) 

NACK to ACK error (for DL-SCH) (10-4 – 10-3) 

CQI block error rate FFS (10-2 – 10-1) 

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

Release 8 105 3GPP TS 36.300 V8.1.0 (2007-06)

Annex I (informative): 

Change history 

Change history (before approval)

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

2006-06 RAN2 Ad. R2-062020 First version. 0.0.0 

2006-06 RAN2 Ad. R2-062026 RLC operation clarified; 

High priority and low priority SRBs listed in RRC; 

New section on RRC procedures; 

Organisation of paging groups explained; 

New section on Support for self-configuration and self-optimisation. 

0.0.0 0.0.1 

2006-06 RAN2 Ad. R2-062036 Four possible types of allocation added to section 11; 

New section for the support for real time IMS services. 

0.0.1 0.0.2 

2006-08 RAN2#54 R2-062206 Annex B on RRC and MAC control added. 

Minor editorial clarifications. 

0.0.2 0.0.3 

2006-09 RAN#34 RP-060603 Section 4 on “Overall Architecture” reorganised; 

Details on RLC operation included (segmentation, PDU size); 

Overview of System Information and RACH procedure added. 

0.0.3 0.0.4 

2006-10 RAN2#55 R2-063012 Ciphering for RRC signalling required in eNB as agreed in SA3; 

Agreements on RLC operation included: concatenation, discard, 

polling and status reports; 

Agreed text proposal in R3-061428 on Self Configuration added to 

section 19; 

Context transfer of header compression at UPE relocation listed as 

FFS. 

Outline of the RACH procedure described. 

0.0.4 0.0.5 

2006-10 RAN2#55 R2-063039 Miscellaneous editorial corrections; 

Agreed text proposal R3-061606 on Current status of E-UTRAN 

Architecture description added to section 4; 

Agreed text proposal in R3-061613 on Support for selfconfiguration and self-optimisation added to section 19. 

Agreed Physical layer model R2-063031 added to section 5 

0.0.5 0.1.0 

2006-11 RAN2#56 R2-063656 Annex C on system information classification added (R2-063064); 

Integrity protection for the control plane only (SA3 agreement); 

Agreements on PDCP and RLC PDU structure/handling reflected; 

Decisions on mobility aspects such as load balancing, handover, 

radio link failure and random access procedure added; 

Agreed MBMS deployment scenarios listed together with MBMS 

transmissions and principles from 25.813; 

Agreed text proposal R3-061936 on Radio Resource Management 

added to section 15; 

Agreed text proposal R3-061940 on RAN Sharing added to section 

10; 

Agreed text proposal R3-061943 on Roaming/Area Restrictions in 

SAE/LTE added to section 10; 

Agreed text proposal R3-062008 on S1 C-Plane Functions and 

procedures added to section 18; 

Agreed text proposal R3-062011 on X2 interface added to section 

19. 

0.1.0 0.2.0 

2006-11 RAN2#56 R2-063680 Incorporation of RAN1 agreement regarding the mandatory support 

of 20Mhz DL bandwidth for UEs i.e. removal of sub-clause 16.1; 

Editorial corrections. 

0.2.0 0.3.0 

2006-11 RAN2#56 R2-063681 Removal of the SA3 agreement on integrity protection for the user 

plane; 

Addition of Annex D on MBMS Transmission; 

Editorial corrections. 

0.3.0 0.3.1 

2006-11 RAN#34 RP-060806 Clean version 0.3.1 0.3.1 

2007-01 RAN2#56

bis 

R2-070403 SA3 agreement on integrity protection for the user plane included 

(R2-070016); 

Annex E on drivers for mobility control added (R2-070276); 

Agreements on the details of the random access procedure added 

in section 10.1.5 (R2-070365); 

New section on UL rate control included (R2-070410); 

RRC security principles listed in section 13.1 (R2-070044); 

Agreement on MAC security added to section 13 (R2-062100); 

Basis for DL scheduling put in section 11.1; 

Assumptions on neighbour cell list included in section 10. 

0.3.1 0.4.0 

2007-02 RAN2#57 R2-070451 Number of bits for RACH in TDD clarified; 

Miscellaneous editorial corrections. 

0.4.0 0.5.0 

2007-02 RAN2#57 R2-071073 Architecture updated according to R3-070397; 

Agreements from R2-070802. 

0.5.0 0.6.0 

2007-02 RAN2#57 R2-071120 RACH model for initial access described; 

Mapping of the BCCH and System Information principles added; 

0.6.0 0.7.0 

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

Release 8 106 3GPP TS 36.300 V8.1.0 (2007-06)

Agreements on DRX included in section 12. 

2007-02 RAN2#57 R2-071122 Miscellaneous clarifications 0.7.0 0.7.1 

2007-02 RAN2#57 R2-071123 CCCH in DL listed as FFS; 

SAE Gateway ID removed from section 8.2; 

PDCP for the control plane listed as FFS in section 4.3.2; 

Agreements on intra-E-UTRAN handover procedure included in 

section 10.1.2 (R3-062020). 

0.7.1 0.8.0 

2007-03 RAN2#57 R2-071124 Agreement on Radio Access Network Sharing (R2-070551) added 

to section 10.1.7; 

Overview of the physical layer (R1-071251) included to section 5; 

Agreed text proposals on S1 interface included in Section 19 (R3-

070289, R3-070402); 

Agreed text proposal R3-070409 on network sharing included in 

section 10.1.7; 

Agreed text proposal R3-070411 on Area Restrictions included in 

section 10.4; 

Agreed text proposal R3-070448 on Assembly of Intra-E-UTRAN 

handover command included in section 10.1.2.1.1; 

Agreed text proposal R3-070451 on inter RAT HO principles

included in section 10.2.2; 

Agreed text proposal R3-070472 on Addressing on S1-C and X2-C

added to sections 19.2 and 20.2; 

Agreed text proposal R3-070494 on Initial Context Setup Function 

and Procedure added to section 19; 

Agreed text proposal R3-070495 on S1 Paging function and 

procedure added to section 19 

Figures for mapping between channels split into Uplink and 

Downlink parts in section 5.3.1 and 6.1.3. 

0.8.0 0.9.0 

2007-03 RAN#35 RP-070136 S1-U and S1-MME used throughout the document; 

aGW replaced by EPC when still used; 

Clean version for information 

0.9.0 1.0.0 

Change history (after approval)

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

2007-03 RP-35 RP-070136 - Approved at TSG-RAN #35 and placed under Change Control 1.0.0 8.0.0 

2007-06 RP-36 RP-070399 

0001 1

Changes to management-, handover-, paging- and NAS 

functions, node- synchronization, X2 UP protocol stack, X2 inter 

cell load management, IP fragmentation, intra-LTE HO, and TA 

relation to cells in eNB 

8.0.0 8.1.0 

RP-36 RP-070494 0002 1 Update on Mobility, Security, Random Access Procedure, etc... 8.0.0 8.1.0 

RP-36 RP-070399 0003 - Update on MBMS 8.0.0 8.1.0 

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