Date post: | 18-Nov-2014 |
Category: |
Documents |
Upload: | smile0life |
View: | 108 times |
Download: | 2 times |
LTE Protocol PrimerWeb presentation 25th June 2008
Wireless Test World 2008Moving into New Era of Wireless
Page 1
3GPP Long Term Evolution (LTE)Protocol Primer
Presented by:Sandy Fraser
June 25, 2008
LTE Protocol PrimerWeb presentation 25th June 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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
• 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
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
eNBUE
PDCP
RLC
MAC
PHY
PDCP
RLC
MAC
PHY
LTE 3GPP Stack overview
3GPP 3.60, Fig 4.3.1User plane protocol stack
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
RLC Segmentation /Concatenation
Page 16
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
………………….
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
MAC PDU with several headers/elements
Page 24
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
Protocol Stack – all together – user data/voice
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
LTE 3GPP Stack overviewHandover measurement scenarios
• 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
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 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 Protocol PrimerWeb presentation 25th June 2008
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+
LTE Protocol PrimerWeb presentation 25th June 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 Protocol PrimerWeb presentation 25th June 2008
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 PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
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!
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
• 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
LTE Protocol PrimerWeb presentation 25th June 2008Page 42
Appendix CQI and MAC
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
CQI and MAC ACK/NACKs
Page 45
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
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008Page 50
Appendix RLC
LTE Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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 Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008Page 55
Appendix PDCP
LTE Protocol PrimerWeb presentation 25th June 2008
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 ??????????
LTE Protocol PrimerWeb presentation 25th June 2008Page 57
Appendix RRC
LTE Protocol PrimerWeb presentation 25th June 2008
LTE 3GPP Stack overviewHandover measurement scenarios
•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
LTE Protocol PrimerWeb presentation 25th June 2008
LTE 3GPP Stack overviewHandover measurement scenarios
• 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
LTE Protocol PrimerWeb presentation 25th June 2008Page 60
Appendix UE categories and Identifiers
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
Appendix – System Architecture Evolution
LTE Protocol PrimerWeb presentation 25th June 2008
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
LTE Protocol PrimerWeb presentation 25th June 2008
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 ?
LTE Protocol PrimerWeb presentation 25th June 2008
Simplified LTE network elements and interfaces
3GPP TS 36.300 Figure 4: Overall Architecture
MME = Mobile Management entity
SAE = System Architecture Evolution
LTE Protocol PrimerWeb presentation 25th June 2008
• 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
LTE Protocol PrimerWeb presentation 25th June 2008
• 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 Protocol PrimerWeb presentation 25th June 2008
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