lte protocol primer

LTE Protocol PrimerWeb presentation 25th June 2008

Wireless Test World 2008Moving into New Era of Wireless

3GPP Long Term Evolution (LTE)Protocol Primer

Presented by:Sandy Fraser

June 25, 2008


Agenda

•High level LTE, SAE

•What is protocol

•The LTE protocol stack

• Data flow through the UE LTE stack

• PHY functions

• RRC – focus on Handovers

•Specifications – status

•Summaries and solutions

•Appendices


LTE major features which affect protocol

Feature CapabilityUE Categories(Provisionally five)

10 Mbps - 300 Mbps on DL5 Mbps to 75 Mbps in UL

Baseline UE capability 20 MHz UL/DL, 2 Rx, one Tx antennaTransmission Time Interval 1 msH-ARQ Retransmission Time

8ms (At LTE peak data rates this is a very hard spec to meet at baseband)

Bearer services Packet only – no circuit switched voice or data services are supported voice must use VoIP


• There is no RNC which dealt with RRC, RLC and MAC elements

• RNC also dealt with packet scheduling (HSDPA Rel 6 moved this to the

node B), this is all moved to the eNB for LTE

• RRM functions have also moved to the eNB

• Radio Admission Control

• Connection Mobility Control

• Dynamic Scheduling of UE resources

eNB functions:differences from 2G/3G

S1 S1

S1 S1X2X2


3GPP TR 23.401 / 25.813

• PLMN – Public Land Mobile Network• EPS – Evolved Packet System• MME – Mobility Management Entity• eNB – E-UTRAN Node B• TAI - Tracking Area ID• E-UTRAN – Evolved Universal Radio

Access Network• C-RNTI – Cell Radio Network

Temporary Identifier• RA-RNTI – Random Access RNTI• UE – User Equipment• IMEI – International Mobile Equipment

Identity• IMSI – International Mobile Subscriber

Identity• S-TMSI – SAE Temporary Mobile

Subscriber Identity


Agenda


•What is protocol



• PHY functions




•Appendices


What is Protocol?

• An agreed-upon set of rules governing the exchange of information.

• “An agreed-upon set of rules” : what, how, and when information is communicated must conform to some mutually acceptable set of conventions referred to as ‘the protocol’

• “Information” : Two types

• “Control” - used to setup, maintain, and end the communication link• “Data” - the actual content that is intended to be exchanged• Packaged into “messages”

• The protocol defines and governs the exchange of messages


Terminology

Inventory ApplFormat message

Coordinate connection state

Handle Data QoS

Add error coding

Format for the media

Appl 2Format message

Appl 3Format message

Coordinate connection state

Handle Data QoS

Check and correct errors

Rx and buffer data

Database ApplExtract info from message

Protocol Stack

Layer

Plane - view across stacks

Peers


Agenda


•What is protocol



• PHY functions




•Appendices


MMSeNBUE

RRC

PDCP

RLC

MAC

PHY

NAS

RRC

PDCP

RLC

MAC

PHY

NAS

LTE 3GPP Stack overview 3GPP 3.60, Fig 4.3.2Control plane protocol stack

Handovers, mobility

Ciphering RoHC

Segmentation, concatenation, ARQ

HARQ, mapping to/from PHY

Modulation, coding


eNBUE

PDCP

RLC

MAC

PHY

PDCP

RLC

MAC

PHY

LTE 3GPP Stack overview

3GPP 3.60, Fig 4.3.1User plane protocol stack


LTE 3GPP Stack overview – PDCP

The main services and functions of PDCP for the user plane include:• Header compression and decompression: ROHC• Transfer of user data between RRC and RLC layers.• Ciphering

The main services and functions of PDCP for the control plane include:• Ciphering and Integrity Protection• Transfer of control plane data between RRC and RLC

layers.

eNBUE

PDCP

RLC

MAC

PHY

PDCP

RLCMAC

PHY


LTE 3GPP Stack overview – PDCP

Robust Header Compression (RoHC)

• For more info see IETF RFC 4995.

• Reduced overhead, more efficient

Once RoHC has been applied the whole packet (data AND header) are ciphered as per 35.201 (data only)

Headers and Message Authentication codes are added

IPHeader Data

Data

PDCP Header C%^b£$^8Df%^!z(£”*v& MAC-I

Ciphered

RoHC applied

Header and data ciphered


Protocol Stack – all together – user data/voice

R R R PDCP SN Octet 1Data Octet 2

………………….Data

MAC ‐ I Oct N‐3MAC ‐ I Oct N‐2MAC ‐ I Oct N‐1MAC ‐ I Octet N

DC RF P FI E SN Octet 1RLC SN Octet 2Data Octet 3Data Octet……

RLC

PDCP

User Voice or Data0111010101100010

CipheredW&V%$C£

To MAC

Add IP HeaderApply RoHC


LTE 3GPP Stack overview - RLC

• Acknowledged Mode (AM)• Unacknowledged Mode (UM)• Transparent Mode (TM)• Error Correction through ARQ (CRC check provided by

the physical layer, that is, no CRC needed at RLC level)• Concatenation, segmentation, re-segmentation of SDU’s

to match transmission (Transport Block – TB) parameters set by MAC

• Re-ordering of PDU’s received out of order• Buffering, timers, state switching.

eNBUE

PDCP

RLC

MAC

PHY

PDCP

RLCMAC

PHY


RLC Segmentation /Concatenation

RLC HeaderRLC Header

RLC Packet Data Unit (PDU)

RLC Service Data Unit (SDU’s)

• Multiple RLC SDU’s are segmented / concatenated into a single RLC PDU

• MAC knows what physical resources are available and RLC provides RLC PDU’s to the size that MAC requests.

• RLC SDU’s can be control information, voice, data etc


LTE 3GPP – RLC, Acknowledged Mode (AM) Acknowledged Mode PDU frame structure • Shown here is a PDU with no additional E & LI fields

showns• If there are an add number of LI fields, there is

additional 4 bits padding. • If there is an even number of LI fields then no

additional padding is necessary.

36.322 Figure 6.2.1.4-1: AMD PDU (No LI)

D/C Data / Control Indicated either Data or Control PDURF Re-segmentation Flag Indicates either a PDU or a PDU segmentP Polling Bit Status report required / not requiredFI Framing Info Segmentation infoSN Sequence Number (5 or 10 bit) Sequence number of the RLC PDUE Extension bit Data or more E and LI to followLI Length indicator Data field length in bytes

DC RF P FI E SN Octet 1SN Octet 2Data Octet 3Data Octet……


LTE 3GPP – RLC, Acknowledged Mode (AM) Acknowledged Mode PDU SEGMENT

D/C Data / Control Indicated either Data or Control PDURF Re-segmentation Flag Indicates either a PDU or a PDU segmentP Polling Bit Status report required / not requiredFI Framing Info Segmentation infoSN Sequence Number (5 or 10 bit) Sequence number of the RLC PDUSO Segment Offset Start/end of PDU portionLSF Last Segment Flag This is the last segment of the PDU

36.322 Figure 6.2.1.5-1: AMD PDU segment (No LI)

DC RF P FI E SN Octet 1SN Octet 2

LSF SO Octet 3SO Octet 4Data Octet 3

………………….Data Octet N


LTE 3GPP – RLC, Acknowledged Mode (AM) Acknowledged Mode STATUS PDU

D/C Data / Control Indicated either Data or Control PDUCPT Control PDU Type Status PDU or TBDACK_SN Acknowledged SN Lowest SN not received or lostNACK_SN Neg. Acknowledged SN SN of PDU detected as lostE1 Extension bit 1 Indicates whether NACK_SN & E2 followsE2 Extension bit 2 Indicates whether SO start/end followSOStart Sequence Offset Start 1st byte of portion of lost PDUSOend Sequence Offset End Last byte of portion of lost PDU

36.322 Figure 6.2.1.6-1: STATUS PDU

DC CPT ACK_SN Octet 1ACK_SN E1 Octet 2

NACK_SN Octet 3E1 E2 NACK_SN Octet 4NACK_SN E1 E2 Octet 5

Sostart Octet 6SOstart Soend Octet 7

Soend Octet 8SOend NACK_SN Octet 9

………………….




………………….Data



RLC

PDCP


CipheredW&V%$C£

To MAC



LTE 3GPP Stack overview – MAC

The main services and functions of the MAC sub-layer include:

• Mapping between upper layers and PHY• Multiplexing/de-multiplexing of RLC PDUs

belonging to one or different radio bearers into/from transport blocks (TB) delivered to/from the physical layer on transport channels

• Error correction through HARQ• Priority handling between UEs by means of

dynamic scheduling• Transport format selection

eNBUE

PDCP

RLC

MAC

PHY

PDCP

RLCMAC

PHYeNB only


LTE 3GPP - MAC Scheduling

• MAC’s main function is the distribution and management of common uplink and downlink resources to multiple UE’s

• eNB MAC must take account of:• Overall traffic volume• UE QoS needs for each connection type.

• If a UE requests resources via a Scheduling request, the eNB mayprovide a scheduling grant identified by C-RNTI (unique identifier provided by RRC) Scheduling grant will also include

• Physical Resource Blocks• Modulation Coding Scheme

• A UE could have several streams of control or user data, identified by Logical Control ID (LCID)


LTE 3GPP - MAC PDU , DL-SCH, UL-SCH• Similar to UMTS – Header, MAC SDU’s, MAC control elements, Padding• Header and SDU’s can be variable in size• MAC PDU Header consists of one or more sub-headers, relating to multiple MAC SDU’s,

MAC control elements or padding• Normally the sub-header contains 6 header fields, R/R/E/LCID/F/L• The LAST sub-header and FIXED sized MAC control elements only have 4 header fields –

R/R/E/LCID

LCID Logical Channel IDL LengthR ReservedE ExtensionF Format

Mac sub‐header with 15 bit L fieldR R E LCID Octet 1F L Octet 2

L Octet 3

MAC sub‐header no L fieldR R E LCID Octet 1

MAC sub‐header with 7 bit L fieldR R E LCID Octet 1F L Octet 2


MAC PDU with several headers/elements

Header 1R R E LCID Octet 1F L Octet 2

Header 2R R E LCIDF L

L………………….

Header N R R E LCIDData Data Oct 1Data Data Oct 2Data

………………….Padding Octet N

• If there are multiple SDU’s in the MAC PDU, then there will be multiple sub-headers

• Each header could be data or control information


LTE 3GPP - MAC HARQ

• N-Process Stop and Wait HARQ• Dowlink

• Asynchronous Adaptive HARQ• PUSCH or PUCCH used for ACK/NACKS for DL (re-)transmissions• PDCCH signals the HARQ process number and if re-transmission or

transmission• Uplink

• Synchronous HARQ• Maximum number of re-transmissions configured per UE• PHICH used to transmit ACK/NACKs for non-adaptive UL (re-)transmissions.

Adaptive re-transmissions are scheduled through PDCCH• 8 UL HARQ processes

• MAC HARQ can also interact with RLC to provide information to speed up RLC ARQ re-segmentation and re-transmission.

• HARQ re-transmissions could be delayed if they collide with GAP measurements required for certain types of Handovers. The GAP Measurements take priority




………………….Data



RLC

PDCP


CipheredW&V%$C£

To MAC




Header 1R R E LCID Octet 1F L Octet 2

Header 2R R E LCIDF L

L………………….

Header N R R E LCIDData Data Oct 1Data Data Oct 2Data

………………….Padding Octet N

RLCMAC

From previous page

To PHY for interleaving and modulation

DC RF P FI E SN Octet 1SN Octet 2

LSF SO Octet 3SO Octet 4Data Octet 3

………………….Data Octet N

DC RF P FI E SN Octet 1SN Octet 2Data Octet 3Data Octet 4

………………….

DC CPT ACK_SN Octet 1ACK_SN E1 Octet 2

NACK_SN Octet 3E1 E2 NACK_SN Octet 4NACK_SN E1 E2 Octet 5

Sostart Octet 6SOstart Soend Octet 7

Soend Octet 8SOend NACK_SN Octet 9

………………….


LTE 3GPP Stack overview – PHY activitiesThe physical layer processing of transport channels consists of the following activities:

• CRC insertion: 24 bit CRC is the baseline for the UL and DL shared channels

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

• Physical-layer Hybrid-ARQ (HARQ) processing;• Scrambling UL: UE-specific scrambling• Scrambling DL: transport-channel specific scrambling on DL-

SCH, BCH and PCH. • Modulation: QPSK, 16QAM, and 64QAM (64 QAM optional

in UE)• Mapping to assigned resources (and antennas for MIMO)

eNBUE

PDCP

RLC

MAC

PHY

PDCP

RLCMAC

PHY


LTE 3GPP Stack overview - RRC

The main services and functions of the RRC sub-layer include:

• Broadcast of System Information , 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

• Security functions including key management• Mobility functions including

– UE measurement reporting for inter-cell and inter-RAT mobility, Inter-cell handover – RRC talks directly with PHY to obtain measurement results

– UE cell selection and reselection and control of cell selection and reselection


LTE 3GPP RRCCell (re)selection and handover procedures

• E-UTRAN Handovers will be possible from:• E-UTRAN<>E-UTRAN• E-UTRAN<>UTRAN• E-UTRAN<>GERAN• E-UTRAN<>Non 3GPP RAN’s

• Handovers will follow general GERAN/UTRAN procedures:

• MS measures neighbour cells• MS reports RxLev, RxQual to BSE/NodeB• When one of the neighbours looks more favourable,

HO or Cell (re)-selection occurs

• However there are some changes in E-UTRAN


LTE 3GPP Stack overviewHandover measurement scenarios

• General concern (36-300, 10.2.3.4) over measurement times for a multi-RAT device

• Full E-UTRAN 20MHz bandwidth• GSM Multi-band access• UTRAN Multi-band access• Non-3GPP (WiMax, CDMA2000 etc) Interworking

• Load Limiting will be controlled by:• E-UTRAN controlling the RAT’s (even frequencies) to be measured• Limiting measurement criteria (TS 25.133)• Awareness of E-UTRAN of UE capabilities• Blind handover support (without measurement reports), FFS• Inter-RAT HO’s will only occur with suitable target cell preparation• Limit the UE to CN signalling – Security, QoS and UE capability contexts

are transferred from source to target



• Intra E-UTRAN Handovers will be affected by differences between the host and targeted neighbour cells:

• Centre Frequency Offset (or lack of)• Bandwidth of target cell is greater or less than host cell

• Gap or no gap decision for cell measurements to assist HO is detailed in 36-300 10.1.3

• RRC controls measurement gaps and patterns• Scheduled gaps• Individual gaps

NGA, No Gap Assistance, GA, Gap Assistance, FFS For Future Study

GANGA NGA GA GAFFS


MMSeNBUE

RRC

PDCP

RLC

MAC

PHY

NAS

RRC

PDCP

RLC

MAC

PHY

NAS

LTE 3GPP Stack overview 3GPP 3.60, Fig 4.3.2Control plane protocol stack

Handovers, mobility

Ciphering RoHC

Segmentation, concatenation, ARQ

HARQ, mapping to/from PHY

Modulation, coding


Agenda


•What is protocol



• PHY functions




•Appendices


How stable are the protocol standardsHow long will this presentation remain current?

RLC and MAC have firmed up considerably over the last 6 monthsRRC, which defines paging, connection control, cell (re-)selection etc still lags behind with several major gaps but has seen many significant additions during recent months.Compare with 36-211, Physical Channels and Modulation, 0xFFS, 54ppFFS – for future study. 3GPP speak for TBDThis presentation relates to the March 2008 release, next release expected late June 2008.

Dec07 pp Dec07 xFFS Mar08 pp Mar08 xFFS

36-321 MAC 23 14 30 20

36-322 RLC 35 16 35 4

36-323 PDCP 26 31 26 19

36-331 RRC 56 151 122 500+


Agenda


•What is protocol



• PHY functions




•Appendices


LTE Summary

Simplified all IP network, with fewer elements and more eNB autonomy

• No RNC, No Soft HO, shorter turnaround times, high data rates, short TTI

Some specifications are almost complete, some are still FFS

• RRC firming up, but still needs much workUMTS comparison:

• Much more autonomy in MAC to reduce higher level processing• Higher layers similar to UMTS – different PDU structure• Some areas more complex because of Diversity, eg CQI, Power control,

re-segmentation, variable block size, more dynamic schedulingPlanned to interwork with existing UMTS and CDMA2000 networks


LTE Protocol Test Needs

• Ideally every field will require to be varied, either to valid or invalid values, and the UE’s responses monitored.

• Force poor radio conditions, re-order, delay and corrupt signalling messages and data

• Test MIMO operation• Force re-transmissions – test HARQ, re-segmentation – test RLC• Test data throughput rates in difficult circumstances

• Analysis tools - Protocol logging of all messages• Access to top and bottom of all protocol layers - Isolation of each layer will

aid troubleshooting. Isolation of protocol stack from PHY allows debug of the stack by itself without the need for chipset.

• Removing the chipset also allows non-real time processing• Some protocol tests will have to be verified through UE RF output eg

Power control, shared channel configuration, timing etc


Coming Soon!

Software Solutions

• ADS LTE Design Libraries

• N7624B Signal Studio

• 89601A VSA Software

Distributed Network

Analyzers

Conformance Network

Digital VSA

VSA, PSA, ESG, Scope, Logic

R&D

Network Analyzers, Power supplies, and More!

MXA/MXG R&D

Agilent 3GPP LTE Portfolio

Signalling

Agilent/Anite SAT LTE –Protocol Development Toolset

Agilent/Anite SAT LTE – UE Protocol Conformance Development Toolset

E6620A Wireless Communications Platform

Drive TestIntroduced

at MWCNEW!

Introduced at MWC

Coming Soon!

Coming Soon!


Agilent and Anite

Providing scalable test solutions to address the complete R&D life cycle for LTE mobile development.• Anite and Agilent are partnering to deliver industry leading UE LTE R&D test

solutions. • Anite will provide industry leading development, conformance and interoperability

protocol test solutions for LTE • Agilent will be providing an industry leading RF platform, OBT based solutions and

RF conformance solutions for LTE. • These solutions will use a common RF hardware platform and a common protocol

stack providing a truly scalable solution to address all phases of UE development –enabling customers to bring LTE UEs to market faster and more efficiently.

Industry Leaders Partnering to Deliver World Class LTE Development Solutions


• Agilent LTE Page: www.agilent.com/find/lte• Wall chart (poster)

• E6620A Page: www.agilent.com/find/e6620a• E6620A Photo Card• LTE Brochure

• Anite web site: www.anite.com

• http://www.anite.com/images/userdocuments/AniteLTE.PDF

Resources

http://www.agilent.com/find/lte

http://www.agilent.com/find/e6620a

http://www.anite.com/

http://www.anite.com/images/userdocuments/AniteLTE.PDF


Appendix CQI and MAC


LTE 3GPP CQI reportingScheduling Mode Periodic CQI reporting

channelsAperiodic CQI reporting channels

Frequency non-selective PUCCH * or PUSCH PUSCH

Frequency selective PUCCH * or PUSCH PUSCH

CQI index modulation coding rate x 1024

efficiency

0 out of range

1 QPSK 78 0.1523

2 QPSK 120 0.2344

3 QPSK 193 0.3770

4 QPSK 308 0.6016

5 QPSK 449 0.8770

6 QPSK 602 1.1758

7 16QAM 378 1.4766

8 16QAM 490 1.9141

9 16QAM 616 2.4063

10 64QAM 466 2.7305

11 64QAM 567 3.3223

12 64QAM 666 3.9023

13 64QAM 772 4.5234

14 64QAM 873 5.1152

15 64QAM 948 5.5547Table 7.2.3-1: 4-bit CQI Table

• CQI/ reporting details 36.213 V8.2.0

• CQI reports can be•Wideband or per subcarrier•Semi static, Higher Layer Configured or UE selected sub-band

•* PUCCH for sub-frames with no PUSCH allocation

•* PUSCH with or without scheduling grant or if no UL-SCH

•Depends on diversity and antenna count

Table 7.2-1: Physical channels for Aperiodic or Periodic CQI reporting


LTE 3GPP CQI reporting

PUCCH Report Type

ReportedPUCCH Reporting Modes

Mode 1-1 Mode 2-1 Mode 1-0 Mode 2-0(bits/BP) (bits/BP) (bits/BP) (bits/BP)

1 Sub-bandCQI

RI = 1 NA 4+L NA 4+L

RI > 1 NA 7+L NA 4+L

2 Wideband CQI/PMI

2 TX Antennas RI = 1 NA NA4 TX Antennas RI = 1 8 8 NA NA2 TX Antennas RI > 1 NA NA4 TX Antennas RI > 1 11 11 NA NA

3 RI 2-layer spatial multiplexing 1 1 1 14-layer spatial multiplexing 2 2 2 2

4 Wideband CQI RI = 1 NA NA 4 4

36.213-820 Table 7.2.2-3: PUCCH Report Type Payload size per Reporting Mode


CQI and MAC ACK/NACKs

Format Bits per sub-frame

Payload Mod’n

1 N/A No Ack/Nack, only SRS N/A1a 1 SISO Ack/Nack BPSK1b 2 MIMO Ack/Nack QPSK2 20 CQI, no Ack/NACK QPSK2a 21 CQI + SISO Ack/Nack B/QPSK2b 22 CQI + MIMO Ack/Nack B/QPSK

Physcial Uplink Control Channel (PUCCH) carries CQI and ACK/NACK information


Synchronous H-ARQ (UL)

#0 #2 #3#1 ……….

H-ARQ process 0

Subframe 0 Subframe 1

• UL LTE utilises synchronous H-ARQ

• Each H-ARQ processes is always sent on the same sub-frame

• If data sent in HARQ process 0, on sub-frame 0 is ACK’d, the next transmission for that process will be on sub-frame 0 of the next frame.

• If data sent in HARQ process 0, on sub-frame 0 is NACK’d, the next re-transmission for that process will be on sub-frame 0 of the next frame.

#2 #3 ……….#0 #1

H-ARQ process 0

Subframe 0 Subframe 1

ACK or NACK received for HARQ process 0


LTE 3GPP - MAC Random Access

• 5 possible RA events1.Initial Access2.Following Radio Link failure3.Handover4.DL data arriving during RRC_Connected5.UL data arriving during RRC_Connected

• 2 types•Contention based (all 5 events)•Non-contention based (only applies to 3, 4)

UE eNB

Random Access Preamble1

Random Access Response 2

Scheduled Transmission3

Contention Resolution 4

Figure 10.1.5.1-1: Contention based Random Access Procedure

Figure 10.1.5.2-1: Non-contention based Random Access Procedure


LTE 3GPP - MAC Random Access

• Random Access is handled by MAC

• UL channel is PRACH• DL Channel is PDCCH• PBCH informs UE of:

• The available PRACH timing and resources.

• Contention Management (number of retries etc)

• When RACH is received, eNB:1.calculates power and timing

based on the received signal2.Assigns RNTI to the UE3.Schedules and uplink grant so

that UE can forward more capability information

Modified 36.300, Figure 19.2.2.3-1


LTE 3GPP - MAC Random Access PDU structure

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

RAID Random Access IDentifierT Type (RAID or OI)R ReservedE ExtensionOI Overload IndicatorTA Timing Advance

E, T, RAID MAC sub header

E T RAID

MAC Random Access Response (RAR)TA Octet 1

TA UL Grant Octet2UL Grant Octet 3UL Grant Octet 4

Temporary C‐RNTI Octet 5Temporary C‐RNTI Octet 6

E, T, R, R, OI MAC sub header

E T R R OI


Appendix RLC


LTE 3GPP – RLC, Transparent Mode (TM)Transparent mode PDU’s are passed on by RLC as received

• No Headers• No Concatenation• No segmentation

Associated with the following logical channels

• BCCH• UL CCCH• DL CCCH• PCCH

36.322 Figure 4.2.1.1.1-1: Model of two transparent mode peer entities


LTE 3GPP – RLC, Unacknowledged Mode (UM)

RLC conducts:

• Segmentation and /or concatenation of PDU’s depending on Transport Block information provided by MAC

• Adds necessary headers• Re-orders out of sequence PDU’s• Detects lost PDU’s• Discard duplicate PDU’s• Timers and state variable initializationAssociated with the following logical channels

• UL and DL DCCH• UL and DL DTCH• MCCH and MTCH

36.322 Figure 4.2.1.2.1-1: Model of two unacknowledged mode peer entities


LTE 3GPP – RLC, Unacknowledged Mode (UM)

RLC is instructed by RRC to use either 5 or 10 bit Sequence Number

The construction of the UM RLC PDU differs for each of these

Data DataFI Framing InfoSN Sequence Number (5 or 10 bit) E Extension bitR1 ReservedLI Length Indicator

36.322 Figure 6.2.1.3-1: UMD PDU with 5 bit SN (No LI)

36.322 Figure 6.2.1.3-2: UMD PDU with 10 bit SN (No LI)


LTE 3GPP – RLC, Acknowledged Mode (AM) For AM RLC conducts:

• Segmentation and /or concatenation of PDU’s depending on Transport Block information provided by MAC

• Adds necessary headers• Re-orders out of sequence PDU’s• Detects lost PDU’s• Discard duplicate PDU’s• Timers and state variable initializationAssociated with the following logical channels

• UL and DL DCCH• UL and DL DTCH

Transmissionbuffer

Segmentation &Concatenation

Add RLC header

Retransmission buffer

RLC control

Routing

Receptionbuffer & HARQ

reordering

SDU reassembly

DCCH/DTCH DCCH/DTCH

AM-SAP

Remove RLC header

36.322 Figure 4.2.1.3.1-1: Model of an acknowledged mode enttiy


Appendix PDCP


LTE 3GPP PDCP frame structure

36.323 Figure 6.2.6.1: PDCP Data PDU format for PDCP status report

Oct 1

Oct 2

Oct N

Oct N-1

Oct N-2

Oct N-3

...

Data

PDCP Sequence NumberR R R

MAC-I

MAC-I (cont.)

MAC-I (cont.)

MAC-I (cont.)

36-323 Figure 6.2.2.1: PDCP Data PDU format for SRBs

D/C Data / Control Indicated either Data or Control PDU

R ReservedMAC-I Message

Authentication Code

Integrity protection and verification

LIS ??????????


Appendix RRC



•E-UTRAN Handovers between neighbouring cells can be either

1.via X2 between eNB’s without EPC intervention–Packets are routed through source eNB until handover is

complete–The only signalling to MME is the “path switch request and ack”

to route packet data to target eNB2.Via MME control if a change of MME/Serving GW is required

–This requires HO to be initiated from the source eNB via the S1 interface to the MME

–The eNB’s may be in different Tracking Area ID’s (TAI)

•eNB’s are much more autonomous than in 2G/3G



• For Handovers, the network can provide some assistance• E-UTRAN – no cell specific assistance or frequency only• UTRAN – frequency list and scrambling codes• GERAN – frequency list. The UE can also “leave” the E-UTRA cell to

read the target GERAN BCH to assess suitability prior to reselection.• UTRAN to E-UTRAN Measurements - UE performs E-UTRAN

measurements in compressed mode• GERAN to E-UTRAN Measurements performed during idle frame, 36-

300, 10.2.3.2 raises some concern over time constraints• General worry 36-300, 10.2.3.4 over measurement times for a multi-

RAT device• Support for non 3GPP Radio technologies is also being discussed


Appendix UE categories and Identifiers


UE categories

In order to scale the development of equipment, UE categories have been defined to limit certain parameters

The most significant parameter is the supported data rates:

UE Category

Max downlink data rate

Number of DL transmit data streams

Max uplink data rate

Support for uplink 64QAM

1 10 Mbps 1 5 Mbps No2 50 Mbps 2 25 Mbps Not yet decided3 100 Mbps 2 50 Mbps Not yet decided4 150 Mbps Not yet decided 50 Mbps Not yet decided5 300 Mbps 4 75 Mbps Yes

All figures provisional from TS 36.306 V8.0.0.The UE category must be the same for downlink and uplink


Appendix – System Architecture Evolution


ePDGEvolvedPacket Core

GPRS Core

Trusted non 3GPP IP Access

WLAN3GPP IP Access

S2b

WLANAccess NW

S5b

IASA

S5a

SAEAnchor

3GPPAnchor

S4

SGiEvolved RAN S1

Op.IP

Serv. (IMS, PSS, etc…)

Rx+

GERAN

UTRAN

Gb

Iu

S3

MMEUPE

HSS

PCRFS7

S6

SGSN

S2a

3GPP TR 23.882

High level SAE Architecture

HSS - Home subscriber server IMS - IP multimedia subsystem Inter AS anchor - Inter access system anchorMME - Mobility management entity Op. IP Serv. - Operator IP service PCRF - Policy and charging rule control functionUPE - User plane entity


Still plenty to define:System Architecture Evolution, open Issues - Annex A 23.882-1f1 Mar08

Open Issues- How to achieve mobility within the Evolved Access System?- Is the evolved access system envisioned to work on new and/or existing frequency band?- Is connecting the Evolved RAN to the pre-SAE/LTE PS core needed?- How to add support for non-3GPP access systems?- WLAN 3GPP IP access system might need some new functionality for Inter-system Mobility with the Evolved Access System- Clarify which interfaces are the roaming interfaces, and how roaming works in general- Inter-access-system mobility- Possible difference between PCC functionality, mainly stemming from the difference in how Inter-AS mobility is provided- How do Ues discover Access Systems and corresponding radio cells ? Autonomous per Access System and the Ues scans/monitors any supported Access System

to discover Systems and cells. Or, do Access Systems advertise other Access Systems to support Ues in discovering alternative Access Systems ? How is such advertising performed (e.g. system broadcast, requested by UE, …) ? How do these procedures impact battery lifetime ?

- In case Access Systems advertise other Access Systems: will any Access System provide seamless coverage (avoiding loss of network/network search), or is a hierarchy of Access Systems needed to provide seamless coverage for continuous advertisement ?

- Is user access control/authentication per access system or more centralized for multiple access systems ?- How are Access Systems, PLMNs and operators discovered and selected ? Can a UE access/attach multiple PLMN/operator in parallel ? If yes, how many ? Or, has

a UE to select the same PLMN/operator for each Access System in case the UE accesses/attaches multiple Access systems in parallel?- How many identities and temporary identities has a UE/subscriber? For every Access System another identity? In case of multiple identities: is user context transfer

and identity translation required at a change of the Access System to avoid re-authentication?- In case a UE accesses/attaches multiple Access Systems in parallel: how does reservation of guaranteed resources work? Are multiple reservations in parallel

required (same resource on every Access System) to allow for fast change between Access Systems ? Or, does a mobility/handover mechanism reserve resources during the mobility/handover process ?

- Shall inter Access System mechanisms and signaling for load sharing and mobility be generic for all Access Systems or peer-to-peer between Access Systems ?- Will any Access Systems have an idle or paging mode ? And, shall the wake-up work over multiple Access Systems (e.g. paging in multiple Access Systems in

parallel) ?- Are User or UE access and service rights specific per Access Systems or common for all or multiple Access Systems ?- How many network nodes are between UE and top level mobility anchor ? And is there only one set traffic plane functions for user data (policing and charging) ? Or,

may the traffic plane functions change during an ongoing service because of an Access System change?- Are there layers of multiple Access Systems in same physical location required ? And how dynamic do Ues change between different Access Systems in the same

location in idle and in connected mode? What signaling traffic is acceptable during such mobility (e.g. signaling via HPLMN) and how does it influence system performance and QoS (e.g. packet loss / service interruption during change of Access System)?

- May functions be transferred to application/services level (e.g. mobility supported by IMS services) ? If yes, to which extent is this feasible for application/services ?- Does every Access System provide its own security mechanisms (encryption, integrity) ? Is a parameter mapping between different security mechanisms possible?

Or, can security associations be established in parallel to ongoing services ?- How is data compression provided for the different access systems ? And how re-synchronizes compression when the access system changes ?


Simplified LTE network elements and interfaces

3GPP TS 36.300 Figure 4: Overall Architecture

MME = Mobile Management entity

SAE = System Architecture Evolution


• Radio Resource Management: • Radio Bearer Control, Radio Admission Control, Connection

• Mobility Control, Dynamic allocation of resources to UEs in both UL and DL (scheduling);

• IP header compression and encryption of user data stream;• Selection of an MME at UE attachment when no routing to an MME can be

determined from the information provided by the UE;• Routing of User Plane data towards Serving Gateway;• Scheduling and transmission of paging messages (from the MME);• Scheduling and transmission of broadcast information (from the MME or O&M);• Measurement and reporting for mobility and scheduling.

eNB functions:The eNB hosts the following functions

S1 S1

S1 S1X2X2


• NAS signalling and NAS signalling security• Inter core network node signalling for mobility between 3GPP access networks• Idle mode UE Reachability (including control and execution of paging

retransmission)• Tracking Area list management (for UE in idle and active mode)• Packet Data Network (PDN) GW and Serving GW selection• MME selection for handovers with MME change• SGSN selection for handovers to 2G or 3G 3GPP access networks• Roaming• Authentication• Bearer management functions including dedicated bearer establishment.

MME functions:The MME hosts the following functions

S1 S1

S1 S1X2X2


LTE 3GPP – S1 and X2

X2 user planeNon-guaranteed delivery of user plane PDU’sIP transport GTP-U on top of UDP/IP

X2 control planeGuaranteed delivery of control plane PDU’sSCTP on top of IP for improved reliability of application layer messaging

S1 key functionsInter-3GPP-RAT HandoversIntra LTE HandoversInitial context setup, modification and release initiated by MME

Security and roamingUE capability and identificationPaging

S1 S1

S1 S1X2X2

lte protocol primer

Business