Wireless White Paper - Intra LTE Mobility

Intra-LTE Mobility Version: 1.1

Alcatel-Lucent – Proprietary Version: 1.00 2/26

Copyright © 2009 by Alcatel-Lucent. All Rights Reserved.

About Alcatel-Lucent Alcatel-Lucent (Euronext Paris and NYSE: ALU) provides solutions that enable service providers, enterprises and governments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies, applications, and services, Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home, at work and on the move. For more information, visit Alcatel-Lucent on the Internet: http://www.alcatel-lucent.com

Notice The information contained in this document is subject to change without notice. At the time of publication, it reflects the latest information on Alcatel-Lucent’s offer, however, our policy of continuing development may result in improvement or change to the specifications described.

Trademarks Alcatel, Lucent Technologies, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective owners. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.


CONTENTS

1 INTRODUCTION ................................................................................................. 4

2 MOBILITY IN ACTIVE MODE ................................................................................... 4

2.1 MEASUREMENT CONTROL AND REPORTING.........................................................................4 2.2 HANDOVER EVENTS ..............................................................................................5 2.3 HANDOVER TYPES................................................................................................6 2.4 HANDOVER STEPS ................................................................................................7 2.5 RAN MOBILITY ..................................................................................................8 2.5.1 Intra-Frequency Handover, intra eNodeB........................................................8 2.5.2 Inter-Frequency Handover, Inter eNodeB........................................................9

2.6 CN MOBILITY.................................................................................................. 15 2.6.1 GTP protocole ...................................................................................... 15 2.6.2 CN HO architecture................................................................................ 16 2.6.3 Scenarios ............................................................................................ 17

3 MOBILITY IN IDLE MODE ......................................................................................19

3.1 IDLE MODE..................................................................................................... 19 3.2 SCENARIO ..................................................................................................... 21

4 QOS OR PERFORMANCE IMPACT ............................................................................22

5 ANNEX ...........................................................................................................23

5.1 INTERFACES ................................................................................................... 23 5.2 QOS .......................................................................................................... 24


1 INTRODUCTION

− The purpose of this document is providing the information on Mobility inside LTE technology. The Mobility procedures are essential to maintain the connections when the users are moving in connected or idle mode.

− This document will not cover the Inter-RAT Mobility (W-CDMA/GERAN to LTE) Please refer to the document: “2G-3G-LTE Mobility Management” for this purpose.

− The Mobility function can be supported through different ways: o RAN Mobility: When the UE moves from one eNB to another eNB within the same sGW. This can

occurs with Intra or Inter-Frequency. o CN Mobility: When the UE moves from one sGW to another sGW. There are two kinds: Intra MME with

changing sGW, Inter MME with changing sGW. In theses two options, the P-GW remains the same.

2 MOBILITY IN ACTIVE MODE

2.1 Measurement control and reporting The decision of the handover is done by the source eNB based on the measurement report sent by the UE in uplink. The measurement control message is an RRC message sent by the source eNB to the UE. The UE sends back the measurement reports indicating:

• The RCID (Radio Cell Identity) of the target cell is the physical Cell identity of the best cell which is the first in the list of neighboring cells. The neighboring cells list may be managed by the same eNB in case of Intra-frequency handover or managed by the remote eNB in case of Inter-Frequency handover


• The RSRP and RSRQ of the serving cell: o RSRP: Reference signal Receiver Power: Average power of resource elements over cell specific

reference signal transmitted on every antenna port. RSRP doesn’t provide any information about Interference.

o RSRQ: Reference signal Receiver Quality: defines to measure the C/I of the reference signal, takes then in consideration the Interference.

2.2 Handover Events One of the following events could trigger the handover measurement:

• Event A1: Serving cells becomes better than threshold. Ms-Hys > thresh

• Event A2: Serving cell becomes worse than threshold Ms-Hys < thresh

• Event A3: neighbor cell becomes better than serving cell Mn+Ofn+Ocn-Hys >Ms+Ofs+Ocs+Off.

• Event A4: neighbor cell becomes better than threshold. Mn+Ofn+Ocn-Hys > threshold

• Event A5: Serving cell becomes worse than threshold1 and neighbor cell becomes better than threshold2 Ms+Hys< threshold1 and Mn+Ofn+Ocn-Hys>threshold2 The parameters involved include:

• Ms : measured RSRP in dBm or/and RSRQ in dB at the serving cell • Mn : measured RSRP or/and RSRQ at the neighbor cell • Hys: Hysteresis in dB • Ofs, Ofn: Frequency specific offset at the serving/neighbor cell. • Ocs, Ocn: Cell specific offset at the serving/neighbor cell. • Thresh: Threshold parameter in dBm or dB. • Thresh1, Thresh2: Predefined Threshold in serving/neighbor cell. In the first step, ALU choices the solution of Blind handover: The triggering condition for PS handover relies on:

o A degradation of the radio conditions on the serving cell o The measured RSRP or/and RSRQ gets lower than a pre-defined threshold without the target cell

measurement (Event A2). The eNB can adjust the measurement parameters to improve the measurement performance.


2.3 Handover types The 3GPP standard allows eNBs to trigger the handover through the S1 or X2 Interface. The X2 handover is performed by eNB and doesn’t allow the MME relocation; only sGW relocation is possible. On the other hand, the S1 handover enables a MME relocation (only EPC, only sGW, or both EPC and sGW relocations). The MME relocation is only permitted in the case of Inter-eNB handover and when the UE leaves the old MME pool area. Please refer to the pool area definition in the Idle mode section. The X2 handover is performed only when the target cell belongs to the same MME pool area as the serving cell. See the below figure: The X2 handover can be achieved from eNB1 to eNB2 but not from eNB1 to eNB3.

eNB2

MME Access Instance No.2

eNB3X 2


S1-C = S1-mme

MME Group ID=mmegi No.1 MME Group ID=

mmegi No.2

MME code= mmec #A

MME code= mmec #B

one MME group = one MME pool


MME code= mmec #A

eNB1X2

MME Pool Area 2

MME Pool Area 1

Overlapping pool area


The preparation phase of the S1 handover is performed through the MME. The eNB takes the decision of the selection of the most appropriate handover mode. The S1 handover is used when the X2 handover can not be performed.

2.4 Handover steps The handover is executed as per the following steps:

• Handover triggering: o Ho decision and request: The source eNB decides to handover the UE to the target eNB based on

event measurement reports and decides to transmit handover request to the target cell o Admission Control RRM: the target eNB can decide to accept or refuse the handover, in function of

the received EPS bearer QoS and the availability of resources of the target cell. • Handover preparation

o Ho command: The source eNB transmits the Handover command to the UE when receiving one acknowledge of handover request from the target cell. The source and the target eNB then synchronize together and the source transmits the buffered data packets to the target.

o SN Status transfer: The source ENB transmits an SN (Sequence number) status transfer message to the target ENB to convey the UL and DL PDCP SN transmit status of EPS bearer. That helps the source maintain both UL and DL synchronization with the target to transfer the buffered data.

• Handover execution o Synchronization: the UE synchronizes with the target eNB. o UL allocation and HO confirm: UE is allocated radio resources on the UL of the target eNB. UE sends

the handover confirm to the target cell. • Data forwarding:

o Path switch request: From target eNB to MME to setup tunnel with the sGW. o Switch downlink path: The serving eNB stops data forwarding packets to the target eNB and the MME

transmits the path switch acknowledge to the target to enable the target eNB to receive the DL data packets directly from the sGW.


2.5 RAN Mobility Both scenarios for Inter-eNB (between two eNB) or intra-eNB (between two sectors of the same eNB) handover are supported. In this case, it is about the X2 Handovers

2.5.1 Intra-Frequency Handover, intra eNodeB The MME relocation can not be done using the X2 handover procedure. In this case, the target eNB must be connected to the MME currently serving the UE. The following figure gives the global view of intra eNB handover.

UE Source ENB MME/SGW

MeasurementReport

measId

measResultServingneighbouringMeasResults

Handover decision

Setup of UE associated resources in the target cell

RRCConnectionReconfiguration

MeasurementConfiguration

MobilityControlInformation

RadioResourceConfigDedicated

UE-RelatedInformation

Switch DL to target cellStart receving UL in target cell

Detach from old cell and synchronize to new cell

Random Access Preamble

Random Access Response

Start transmitting DL in target cell

Release UE associated resources in the source cell

UE Source ENB MME/SGW

DL Data

RRCConnectionReconfigurationComplete


2.5.1.1 Data PS call on going S1 or X2 data forwarding means that the source eNB continues to forward the data packets to UE either directly through X2-u through the target eNB or through the sGW during the Handover Execution phase

2.5.1.2 CS call on going TBD.

2.5.2 Inter-Frequency Handover, Inter eNodeB The Inter-Frequency handover is useful in the context of a deployment where different frequencies are used either in different regions for coverage purpose or in the same region to offer the higher capacity users Both X2 and S1 based Handovers intra LTE are supported. Inter-eNB handover is triggered by the reception of measurement report in which the best reported cell is managed by a different eNB than the serving cell.

2.5.2.1 Inter-frequency intra-band This feature consists of a UE moving from one cell handling a LTE frequency (f1) to another cell handling a second LTE frequency (f2), but within the same frequency band. The eNB instructs the UE to measure neighbor frequency cell.

2.5.2.2 Inter-frequency Inter-band This feature consists of a UE moving from one cell of LTE frequency (f1) to another cell of LTE frequency (f2) in another frequency band. The eNB instructs the UE to measure neighbor frequency cell Inter-frequency Inter-band (ie on different frequencies and different bands). The Alcatel-Lucent eNB has the capability to support multiband. One Modem card can indeed be dedicated to a given frequency band. The eNB can then support up to three different bands by the means of 3 Modem cards. One band can support three sectors Different possible combinations of BW on different bands are: 5 MHz + 5 MHz, 5 MHz + 10 MHz, 10 + 10 MHz


2.5.2.3 Scenario The following figures give the global view of Inter eNB handover

2.5.2.3.1 Source eNB, Handover preparation phase The source eNB sends in the Handover Request the UL GTP tunnel endpoint towards sGW in UL and QoS profiles of theses bearers and the DL forwarding request for each bearer.


2.5.2.3.2 Source eNB, Handover execution phase

2.5.2.3.3 Source eNB, Handover completion phase

DL Data

DL Data

UE Source ENB MME/SGWTarget ENB

RRCConnectionReconfiguration SN STATUS TRANSFERSAE Bearers Subject to Status Transfer ListDetach from old cell and

synchronize to new cell

PATH SWITCH REQUESTSAE Bearer To Be Switched in Downlink List

DL Data Forwarding

DL DataPATH SWITCH REQUEST ACKNOWLEDGE

U-plane actions

Release UE context and associated resources Release X2 resources

UE Source ENB Target ENB MME/SGW

Path switch


UE CONTEXT RELEASE

Random Access PreambleRandom Access Response

D L D a ta (En d Ma rke r)

D L D ata F or w ar ding ( End Mar k er )

DL DataDL Data Forwarding

DL Data

DL Data

DL Data F or war ding ( E nd M ar ker )


SN STATUS TRANSFERSAE Bearers Subject to Status Transfer ListDetach from old cell and



DL Data Forwarding


U-plane actions



Path switch


UE CONTEXT RELEASE



DL DataDL Data Forwarding

D L D a t a ( E n d Ma r k e r )


2.5.2.3.4 Target eNB, Preparation phase The data forwarding is requested by each bearer through the Handover Request from the serving eNB. If the target eNB accepts this kind of bearer, it will return each E-RAB for which resources will be prepared in the target and the associated DL GTP tunnel endpoint Source ENB Target ENB

Handover decision

HANDOVER REQUESTTarget Cell IDSAE Bearers to be Setup ListRRC Context

Setup of UE context and associated resources

HANDOVER REQUEST ACKNOWLEDGESAE Bearers Admitted List

Target eNodeB to Source eNodeB Transparent Container

U-plane actions U-plane actionsSN STATUS TRANSFERSAE Bearers Subject to Status Transfer List

Source ENB Target ENB

UE


UE

U-plane actions

RRCConnectionReconfigurationMeasurementConfigurationMobilityControlInformation

RadioResourceConfigDedicatedUE-RelatedInformation


2.5.2.3.5 Target eNB, Handover execution phase

D L D a t a (En d Ma rk e r)

DL Data Forwardi ng (End M ark er)


U-plane action DL DataDL Data Forwarding






U-plane action

DL Data Forwarding


RELEASE RESOURCE

Continue delivering in-transit packets


DL Data


Path switch

DL Data







2.5.2.3.6 Target eNB, Handover completion phase The target eNB sends the Path Switch Request when the UE has completed changed the cell and prepares to receive the DL data as soon as the MME switch the DL data path to the target eNB and stops the data transmission towards the source eNB.

DL Da t a ( E n d Ma r k e r )

DL Da ta F o rwa rd in g (En d Ma rk e r)


U-plane action DL DataDL Data Forwarding




RrcConnectionReconfigurationComplete


U-plane action

DL Data Forwarding


UE CONTEXT RELEASE

Continue delivering in-transit packets


DL Data


Path switch

DL Data







2.6 CN Mobility 2.6.1 GTP protocol The IP packet in DL addressed to the UE is first received by PGW. The PGW repackages the user data and encapsulates inside a tunnel with an IP header (sGW IP ) and the GTP tunnel ID is the S5/S8 EPS bearer. The sGW strips off the IP packet and repackaged by encapsulating inside a tunnel with an IP header eNB and EPS BR associated with the UE. The eNB then strips off the encapsulation header and transmits the payload to the UE on Uu Interface.

SGW PGW MME

ENB

Radio bearers

S1-U GTP-U

S5/S8 GTP-C GTP-U (Default) GTP-U (Dedicated)

S1-MME GTP-C

S11 GTP-C

APN1 VOICE

APN2 HSI

UE APN1, APN2


2.6.2 CN HO architecture The S1 Handover can be achieved with following possible configurations:

• sGW relocation without MME • Both sGW relocation and MME • MME relocation without sGW. • S1 handover without any node EPC relocation. The MME is responsible of deciding the sGW or/and MME relocations. After the handover, new EPS S1 and EPS BS S5/S8 are created from the UE through the target eNB, target sGW and P-GW. In LA2.0 there is only Intra-frequency S1 handover is supported.


2.6.3 Scenarios 2.6.3.1 Intra-MME/Inter-sGW The data forwarding is processed as follows in case of sGW relocation: The downlink traffic is sent by the PGW towards the target sGW through the Serving sGW.

2.6.3.2 Inter-MME/Inter-sGW The Relocation MME can not be performed unless the UE leaves a given pool area to enter a different pool area. The both MME and sGW relocation is described as following: The source MME decides the MME relocation where the EPS bearer is created on the new target sGW

Downlink traffic

UESource

eNBTargeteNB

SourceMME

TargetSGW

PDNGW

Downlink & uplink traffic

1. Handover Initiation

2. Handover Preparation

4. Path switch


ServingSGW

3. Handover Execution

indirect forwarding

Uplink traffic

Downlink traffic

UESource

eNBTargeteNB

SourceMME

TargetSGW

PDNGW




4. Path switch


ServingSGW


indirect forwarding

UESource

eNBTargeteNB

SourceMME

TargetSGW

PDNGW




4. Path switch


ServingSGW


indirect forwarding

Uplink traffic


UE

Source eNodeB

Source MME

Source Serving GW PDN GW

Target MME

Target Serving GW

Target eNodeB


HSS

16. Update Bearer Request

17. Update Bearer Response

15. Update Bearer Request

Downlink User Plane data

2. Handover Required

Downlink User Plane data

1. Decision to trigger a relocation via S1

3. Forward Relocation Request

5. Handover Request

5a. Handover Request Acknowledge

7. Forward Relocation Response

9. Handover Command

9a. RRC Connection Reconfiguration

11a. Only for Direct forwarding of data

12. RRC Connection Reconfiguration Complete Downlink data

13. Handover Notify

14. Forward Relocation Complete

14b. Forward Relocation Complete Acknowledge

16a. Update Bearer Response

.

8a. Create Bearer Response

(A)

11b. Only for Indirect forwarding of data

18. Tracking Area Update procedure

19c. Delete Bearer Request

(B) 19a. UE Context Release Command

Uplink User Plane data

8. Create Bearer Request





19b. UE Context Release Complete 19d. Delete Bearer Response

20a. Delete Bearer Request

20b. Delete Bearer Response

21a. Delete Bearer Request

21b. Delete Bearer Response

10. eNB Status Transfer

10c. MME Status Transfer

10a. Forward SRNS Context 10b. Forward SRNS Context Ack


3 MOBILITY IN IDLE MODE

3.1 Idle mode The UE is in idle mode when there are no NAS signaling between the UE and the network, there is no context set up in the eNB for a given UE but the UE is registered at MME with the default EPS BR. The benefit of idle mode mobility consists of an exchange of information via Paging, saving network resources and battery power in the UE. The Idle mode Mobility is split into 3 levels: Tracking area TA: is a logical grouping of eNB in a contiguous region for the purpose of paging the UE. The tracking area update TAU procedure allows the network (UE or Network?)to identify his location when he is moving from one TA to another TA without sending data pacquets. TAI= TA code+ PLMN Id In LTE, the cell can be a member of only one TAI but the UE can be registered in one and more TAI. The serving MME can be changed as UE moves. The UE information context is then transferred on S10 from the old MME to the new MME: Paging information, UE service data flows, EPS BR, information on associated sGW and P-GW. Cell reselection: There are 504 different physical-layers cell ID in LTE. Each of them corresponds to a unique DL reference signal sequence. The UE uses Primary and secondary signals in DL to search the intra and Inter-frequencies. If the UE can not find a suitable LTE cell, it will attempt to search another cell technology in its geographical area: 3GPP/2 technologies as GSM, UMTS or CDMA or non-3GPP/2 technologies like WiMAX or WiFi. Theses cell changes are called IRAT or Inter-Radio Access technology. There are 510 Physical cell ID, are grouping into 170 Physical cell ID group. Each group contains id from 0 to 2. Each Physical cell ID group contains from 0 to 169 physical cell ID. Radio Cell Identity= 3* Physical cell ID group + Identity within group resulting an Integer value 0 to 503. PLMN selection: In future releases there is a possibility for the UE to select the preferred PLMN. It is based on the PLMN ID information in the broadcast channel. Theses three information (TAI, Cell ID and PLMN ID) are contained in the SIB information part of the broadcast channel (Logical channel BCCH and Transport channel S-BCH and DL-SCH) The Call IP in eCCM or xCCM-U card is responsible for system information building


The following picture describes how several eNBs can be regrouped into one TA. The fact some contiguous eNB belonging to one TA eases the paging UE which can be performed on one or many TA where the mobile is located. Several eNBs are connected to the same SGW and one eNB can belong to two contiguous SGW to avoid the SGW relocation during mobility.

Al l Rights Reserved© Al catel -Lucent 20076 | A LU LTE for B ouygues, L a Boursid ière | June 30, 20 08

EPC background3GPP EPC topology model

eNB

TA1 ... TA4

SGW1

eNBeNB

MME1

MME2

SGW3

SGW4

SGW2

eNB eNB eNB eNB eNB eNB eNB

MME Pool 1 MME Pool 2

SGW Area 1 SGW Area 2 SGW Area 3 SGW Area 4

TA8TA1 TA2 TA3 TA4 TA5 TA6 TA7

MME3

MME4

TA3 ... TA8


3.2 Scenario A TAU procedure is triggered by the UE either by the expiry of the period timer or by the UE’s entry into a new TA. The UE initiates the TAU procedure by sending a TAU request to the MME through the current eNB.

(A)

4. Context Request 2. TAU Request

new MME old MME/ old S4 SGSN

new Serving GW PDN GW HSS

5. Context Response 6. Authentication / Security

12. Update Location 13. Cancel Location

14. Cancel Location Ack 16. Delete Bearer Request

17. Delete Bearer Response 18. TAU Accept

19. TAU Complete

7. Co ntext Acknowledge

old Serving GW

3. TAU Request

eNodeB UE

11. Create Bearer Response

8. Create Bearer Request 9. Update Bearer Request 10. Update Bearer Response

15. Update Location Ack

(B)

1. Trigger to start TAU procedure


4 QOS OR PERFORMANCE IMPACT Each EPS bearer is a logical link between the UE and PGW; it is associated with three parameters: QCI, Label and ARP. During the Handover the EPS bearer must be transferred from the old to the new MME in case of MME relocation. The receiving MME needs to develop a bearer with the same characteristics: TBC. The S1 Handover Interruption time shall be higher than the X2 handover Interruption due to MME relocation. For this purpose, the X2 handover is preferred over S1 handover.


5 ANNEX

5.1 Interfaces

UE eNB

MME

ServingGW

PDNGW

UTRAN

GERANSGSN

S1-U (GTP-U)

S11 (GTP-C)

S4 (GTP-C/U)

S12 (GTP-U)

S5 (GTP-C/U)

PDNGW

HSGWCDMA2000

S8 (GTP-C/U)

S2 (PMIPv6)

PCRF

S5 (PMIP)

Gx

Gx/c

S103 (GRE)

UE eNB 1

MME 1

ServingGW

PDNGW

UTRAN

GERANSGSN

S1-U (GTP-U)

S11 (GTP-C)

S4 (GTP-C/U)

S12 (GTP-U)

S5 (GTP-C/U)

PDNGW

HSGWCDMA2000

S8 (GTP-C/U)

S2 (PMIPv6)

PCRF

S5 (PMIP)

Gx

Gx/c

S103 (GRE)X2

eNB 2

MME 2S10

S10

S10


5.2 QoS Each EPS bearer is a logical link between the UE and PGW; it is associated with three parameters:

• QCI: QoS identifier associated with a Label which is the set of parameters, including Bearer type, Priority, Parquet delay, Parquet loss.

• Bearer type: GBR “guaranteed bit rate”, MBR, “maximum bit rate”, AMBR “aggregate MBR” • ARP: priority of allocation or retention: The main purpose is to decide whether the bearer can be accepted or

removed in case of resource limitation.

3 (Bronze)2 (Silver)

1 (Gold)9sharing, progressive video, etc.)9Non-GBR


1 (Gold)8Video (Buffered Streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file 8Non-GBR


1 (Gold)7Voice, Video (Live Streaming), Interactive Gaming7Non-GBR


1 (Gold)6

Video (Buffered Streaming)TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

6Non-GBR


1 (Gold)5Non-Conversational Video (Buffered Streaming)4GBR


1 (Gold)4Conversational Video (Live Streaming)2GBR


1 (Gold)3Real Time Gaming3GBR


1 (Gold)2Conversational Voice1GBR

3 (Bronze)2 (Silver)1 (Gold)

1IMS Signalling5Non-GBR

ARP Priority(Up to 14 prio)PriorityExample ServicesQCIResource

Type


1 (Gold)9sharing, progressive video, etc.)9Non-GBR


1 (Gold)8Video (Buffered Streaming)

TCP-based (e.g., www, e-mail, chat, ftp, p2p file 8Non-GBR


1 (Gold)7Voice, Video (Live Streaming), Interactive Gaming7Non-GBR


1 (Gold)6

Video (Buffered Streaming)TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

6Non-GBR


1 (Gold)5Non-Conversational Video (Buffered Streaming)4GBR


1 (Gold)4Conversational Video (Live Streaming)2GBR


1 (Gold)3Real Time Gaming3GBR


1 (Gold)2Conversational Voice1GBR

3 (Bronze)2 (Silver)1 (Gold)

1IMS Signalling5Non-GBR

ARP Priority(Up to 14 prio)PriorityExample ServicesQCIResource

Type


QCI Resource Type

Priority Packet Delay Budget (NOTE 1)

Packet Error Loss Rate (NOTE 2)

Example Services

1 (NOTE 3)

2 100 ms 10-2 Conversational Voice

2 (NOTE 3)

GBR

4 150 ms 10-3 Conversational Video (Live Streaming)

3 (NOTE 3)

3 50 ms 10-3 Real Time Gaming

4 (NOTE 3)

5 300 ms 10-6 Non-Conversational Video (Buffered Streaming)

5 (NOTE 3)

1 100 ms 10-6 IMS Signalling

6 (NOTE 4)

6

300 ms

10-6

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)

7 (NOTE 3)

Non-GBR 7

100 ms

10-3

Voice, Video (Live Streaming) Interactive Gaming

8 (NOTE 5)

8

300 ms

10-6

Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file

9 (NOTE 6)

9 Sharing, progressive video, etc.)


End of Document

Documents

Wireless White Paper - Intra LTE Mobility