HSDPA optimzation

HSDPA Network Optimization

& Troubleshooting

INACON GmbHKriegsstrasse 15476133 Karlsruhe

Germanywww.inacon.com

e-mail: [email protected]

Cover design by Stefan Kohler

© 1999 - 2008 INACON GmbHKriegsstrasse 15476133 Karlsruhe

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this publication, the publisher and authors assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained herein. For more information, contact INACON GmbH at www.inacon.com.

http://www.inacon.com/

HSDPANetwork Optimization

&Troubleshooting

Stefan Blomeier

Legend:All INACON publications use the same color codes to distinguish mandatory from optional or conditional parts in frame formats or optional from mandatory data blocks or signaling messages in scenarios. The different color codes are explained underneath:

• Color Codes in Frame Formats:

• Color Codes in Scenarios:

Signaling Message

(mandatory)

Signaling Message

(optional)

Data

(mandatory)

Data

(optional)

kForeword of the Publisher:Dear Reader:

Note that this book is primarily a training document because the primary business of INACON GmbH is the training and consulting market for mobile communications. As such, we are proud to providing high-end training courses to many clients worldwide, among them operators like AT&T Wireless, INMARSAT or T-MOBILE and equipment suppliers like ERICSSON, MOTOROLA, NOKIA or SIEMENS.

INACON GmbH is not one of the old-fashioned publishers. With respect to time-to-market, form-factor, homogenous quality over all books and most importantly with respect to after-sales support, INACON GmbH is moving into a new direction. Therefore, INACON GmbH does not leave you alone with your issues and this book but we offer you to contact the author directly through e-mail ([email protected]), if you have any questions. All our authors are employees of INACON GmbH and all of them are proven experts in their area with usually many years of practical experience.

The most important assets and features of the book in front of you are:

• Extreme degree of detailed information about a certain technology.• Extensive and detailed index to allow instant access to information about

virtually every parameter, timer and detail of this technology.• Incorporation of several practical exercises.• If applicable, incorporation of examples from our practical field

experiences and real life recordings.• References to the respective standards and recommendations on virtually

every page.

Finally, we again like to congratulate you to the purchase of this book and we like to wish you success in using it during your daily work.

Sincerely,

Gunnar Heine / President & CEO of INACON GmbH

PS: Please check for our UMTS online encyclopaedia at www.inacon.com.

http://www.inacon.com/

- 9 -

HSDPA Network Optimization & Troubleshooting

Table of ContentsTable of Contents

HSDPA in Practice......................................................12HSDPA Channel Overview ................................................................................... 15 Example of HSPA Drive Testing with TEMS ....................................................... 21

(1) CQI during HSxPA Serving Cell Change ................................................................ 21 (2) HSDPA various Throughput Rates.........................................................................24(3) HS-DSCH Retransmission and BLER.....................................................................26(4)HS-DSCH Hybrid Automatic Repeat Request Processes........................................28(5) HS-SCCH Decoding...............................................................................................30(6) Iub-Bandwidth Limitation or bad Flow Control between NodeB and RNC...............32HS-PDSCH Symbol Rate ............................................................................................. 34 Code Rate R ................................................................................................................ 34 HSDPA Throughput versus SIR – Simulation..............................................................38

QPSK with Code Rate R ¼.................................................................................................38QPSK with Code Rate R ½.................................................................................................38QPSK with Code Rate R ¾.................................................................................................3816-QAM with Code Rate R ½..............................................................................................3816-QAM with Code Rate R ¾ .............................................................................................38HSDPA Throughput according to Antti Toskala....................................................................40

CPICH variation versus MPO variation........................................................................44Session Throughput versus CPICH Power and MPO..................................................46Application Throughput vs. CPICH Power and MPO....................................................48CQI versus Ec/No........................................................................................................50Can 15 HS-PDSCH’s Codes be really allocated?........................................................52Solutions to the Problem of Code Shortage.................................................................54

Introduce 2nd UMTS Frequency..........................................................................................54F-DPCH in Rel. 6..................................................................................................................54Dynamic Code Tree Allocation between R99 and HS-PDSCHs...........................................56

Semi Dynamic Code Tree Allocation ............................................................................ 56 Dynamic Code Tree Allocation ..................................................................................... 56 Physical Shared Channel Reconfiguration...................................................................58CQI mapping table for UE Categories 1-6, 7-8, 9 and 10.............................................65HSDPA during Compressed Mode Operation..............................................................67(1) Inter Frequency Handover – Event 2D....................................................................69(2) Inter Frequency Handover – Compressed Mode Parameter...................................71(3) Inter Frequency Handover – Compressed Mode Parameter...................................73Radio Bearer Setup: .................................................................................................... 75 Radio Bearer Release: ................................................................................................ 75 Radio Bearer Reconfiguration: .................................................................................... 75 Cell Update Confirm ..................................................................................................... 75 Transport Channel Reconfiguration: ........................................................................... 75 Physical Channel Reconfiguration: ............................................................................. 75

HS-DSCH Capacity Request procedure .............................................................. 89 HS-DSCH DATA FRAME ....................................................................................... 97

© INACON GmbH 1999-2008.All rights reserved. Reproduction and/or unauthorized use of this material is prohibited and will be prosecuted to the full extent of German and international laws. Version Number: 1.2

- 10 -


(1) Understanding Flow Control Flow Control over HSDPA ........................... 105 (2) Understanding Flow Control Flow Control over HSDPA ........................... 107 (3) Understanding Flow Control Flow Control over HSDPA ........................... 109 Flow Control of Cat 8 .......................................................................................... 113 .............................................................................................................................. 114 Iub Flow Control .................................................................................................. 115

Solutions for Practical Exercises............................116


- 11 -


Intentionally left blank


- 12 -

HSDPA Troubleshooting

HSDPA in Practice

- 13 -


ObjectivesObjectivesAfter this Lecture the Student will be able to:

• State the import parameters in drive-test log to evaluate the HSDPA throughput performance

• State the new channels of HSDPA and how they operate and get configuredvia RRC

• Analyse throughput issues on Iub HS-DSCH Flow Control

• Review the impact of CPICH Power on CQI and MPO

- 14 -


HSDPA Channel OverviewHSDPA Channel Overview

DTCH

HS-DSCH

n x HS-PDSCH’sSF 16

HS-SCCH (1…4)SF 128

HS-DPCCH SF 256

User Data e.g. TCP/IP frames (FTP, HTTP, SMTP, POP, …)

UE-id and HS-DSCH related control info

ACK / NACK, CQI

new-H-RNTI Binary string (Bin) : 0000000000000000------------------------------------------ rb-MappingInfo RB-MappingInfo-r5 : [0 ] : ul-LogicalChannelMappings UL-LogicalChannelMappings : oneLogicalChannel oneLogicalChannel ul-TransportChannelType UL-TransportChannelType : dch dch : 21 rlc-SizeList : allSizes mac-LogicalChannelPriority : 8 dl-LogicalChannelMappingList DL-LogicalChannelMappingList-r5 : [0 ] : dl-TransportChannelType DL-TransportChannelType-r5 : hsdsch hsdsch : 0-------------------------------------------------------------------[1 ] : dl-TransportChannelType DL-TrCH-TypeId1-r5 : hsdsch tfs-SignallingMode : hsdsch hsdsch harqInfo numberOfProcesses : 6 memoryPartitioning : implicit addOrReconfMAC-dFlow mac-hs-AddReconfQueue-List

mac-hs-AddReconfQueue-List[0 ] : mac-d-PDU-Size : 656 mac-d-PDU-Index : 0----------------------------------------------------------deltaACK : 7 deltaNACK : 7 ack-NACK-repetition-factor : 1----------------------------------------------------------dl-HSPDSCH-Information hs-scch-Info modeSpecificInfo : fdd hS-SCCHChannelisationCodeInfo : [0 ] : 4 [1 ] : 5 [2 ] : 6 [3 ] : 7 measurement-feedback-Info modeSpecificInfo : fdd measurementPowerOffset : 21 feedback-cycle : fc2 cqi-RepetitionFactor : 1 deltaCQI : 7--------------------------------------------------dl-InformationPerRL-List DL-InformationPerRL-List-r5 : [0 ] : modeSpecificInfo : fdd primaryCPICH-Info primaryScramblingCode : 390 servingHSDSCH-RL-indicator : True

- 15 -


HSDPA Channel OverviewHSDPA Channel Overview

- 16 -


Practical Exercise:Practical Exercise:

- 17 -


Please fill in the Physical Channel Names!Please fill in the Physical Channel Names!

Answer:

- 18 -


Example of HSDPA OperationExample of HSDPA Operation in ROMES in ROMES

- 19 -


Example of HSDPA Operation in ROMESExample of HSDPA Operation in ROMES[ROMES Drive test tool (Rohde & Schwarz)]

- 20 -


- 21 -


Example of HSPA Drive Testing with TEMSExample of HSPA Drive Testing with TEMS(1) CQI during HSxPA Serving Cell Change

• CQI goes with Ec/No of the serving HSxPA cell, so late change of HSXPA serving cell leads to low HSDPA throughput in mobility

- 22 -


- 23 -


(2) HSDPA various Throughput Rates(2) HSDPA various Throughput Rates• Ec/No of HS Serving Cell CQI HS Physically Requested Throughput HS Physically Scheduled Thp HS

Physically Served Thp

- 24 -


- 25 -


(3) HS-DSCH Retransmission and BLER(3) HS-DSCH Retransmission and BLER• HS-DSCH NACK Rate ~ HS-DSCH Retransmission Rate ~ HS-DSCH BLER 1st Transmission

- 26 -


- 27 -


(4)HS-DSCH Hybrid Automatic Repeat Request Processes(4)HS-DSCH Hybrid Automatic Repeat Request Processes• HS-DSCH HARQ Processes: max 8; typical 6 for Cat 6 and Cat 8, 9 and 10

- 28 -


- 29 -


(5) HS-SCCH Decoding(5) HS-SCCH Decoding• HS-SCCH Decode Success Rate: shows how often the UE is scheduled

- 30 -


UTRAN SW, Backpressure = 35%With TCP/IP Optimizer for Windows XP

UTRAN SW, Backpressure = 25%3xE1

good Ec/No and thus good CQI, but there is QPSK, so there was no data to be transmitted!!! As there is only 1 hs-scch, codes are not shared with other user(s).

good Ec/No but HSDSCH decoding success rate is not 100% means that the UE was not scheduled all the time.

- 31 -


(6) Iub-Bandwidth Limitation or bad Flow Control between(6) Iub-Bandwidth Limitation or bad Flow Control between NodeB and RNCNodeB and RNC• UTRAN/NodeB SW shows that 3xE1 sites are limiting the throughput on the Iub interface due to small back pressure

values? (other possibility would be lack of DL power – not realistic)

- 32 -


Throughput and Code Rate RThroughput and Code Rate R

• QPSK: 2 bits/symbol * 240 Ksymbols/s * #HS-PDSCH’s

• 16-QAM: 4 bits/symbol * 240 Ksymbols * #HS-PDSCH’s

• R(QPSK) = TBS / (n * 960 bits)

• R(16-QAM) = TBS / (n * 1920 bits)

- 33 -


Throughput and Code Rate RThroughput and Code Rate RHere we would like to focus on the user plane throughput and physical amount of bit to be transferred.

HS-PDSCH Symbol Rate3.84 Mcps / (16 chips/symbol) = 240 Ksymbols/sNumber of Bits per TTI with QPSK and 16-QAM

240 Ksymbols * {2 | 4 [bits/symbols]} * 2 ms * #HS-PDSCH’s

Results:QPSK: 960 bits per HS-PDSCH16-QAM: 1920 bits per HS-PDSCH

Code Rate RR = (Payload bits before Turbo Coding) / (Output after Turbo Coding and Rate Matching)

- 34 -


Achievable Throughput without RetransmissionsAchievable Throughput without Retransmissions

- 35 -


Achievable Throughput without RetransmissionsAchievable Throughput without RetransmissionsMax throughput = R * {2 | 4 [bits/symbol]} * 240 ksymbol/s * #HS-PDSCH’s

• (1) Example: QPSK with R = 3/4 and 10 HS-PDSCH’sMax throughput = 3/4 * 2 bits/symbol * 240 ksymbol/s * 10 = 3.6 Mbit/s

• (2) Example: 16-QAM with R = 2/4 and 10 HS-PDSCH’sMax throughput = 2/4 * 4 bits/symbol * 240 ksymbol/s * 10 = 4.8 Mbit/s

- 36 -


HSDPA Throughput versus SIR – SimulationHSDPA Throughput versus SIR – Simulation

- 37 -


HSDPA Throughput versus SIR – SimulationHSDPA Throughput versus SIR – SimulationQPSK with Code Rate R ¼240 Ksymbols x 2 Bits/Symbol x ¼ = 120 kbit/s per HS-PDSCH

QPSK with Code Rate R ½240 Ksymbols x 2 Bits/Symbol x ½ = 240 kbit/s per HS-PDSCH

QPSK with Code Rate R ¾240 Ksymbols x 2 Bits/Symbol x ¾ = 360 kbit/s per HS-PDSCH

16-QAM with Code Rate R ½240 Ksymbols x 4 Bits/Symbol x ½ = 480 kbit/s per HS-PDSCH

16-QAM with Code Rate R ¾ 240 Ksymbols x 4 Bits/Symbol x ¾ = 720 kbit/s per HS-PDSCH

- 38 -


HSDPA Throughput according to Antti ToskalaHSDPA Throughput according to Antti Toskala

- 39 -


HSDPA Throughput according to Antti ToskalaHSDPA Throughput according to Antti ToskalaUsually a proportional fair resource scheduler is used in HSDPA.The Network Efficiency or Effective Load for a UMTS System is best (load is lowest) for a BLER between 10% ... 20% up to 30%. Depending on UE speed and channel interference characteristic (e.g. indoor, outdoor macro cell, micro cell), more orless BLER gives better System Performance.The lower the Eb/No and amount of (re-)transmissions is/are for successful decoding, the less Noise/Interference is generated and the higher System Capacity in UMTS gets. Unfortunately, the lower Eb/No is, the more retransmission might be necessary for successful decoding (depending on the interference channel characteristics) and the higher the BLER becomes. With higher BLER however, time and power is wasted so the system becomes inefficient again. So somewhere between 1% BLER and 70% BLER there is an optimum where BLER and Eb/No for successful decoding offer the most benefit for UMTS System Capacity. And that BLER versus Load relation is best for about 20% BLER based on first transmission.I want to emphasize that the UE has to be delivered with a CQI fitting to 10 % BLER otherwise it will fail acceptance test. It is up to the NodeB to allow the UE to cheat by adding an offset to the CQI or by requesting an offset to the measured CPICH power. Actually there is a potential harm: Since a higher BLER will result in more retransmission the latency of the system will be increased. This might lead to more latency than tolerated by the QoS. FYI: LTE (Long Term Evolution project of 3GPP) calculates with 30% BLER.Is there any harm caused to the network if more and more UE's cheat in their CQI reporting and report CQI for e.g. 20% BLER (single retransmission)instead of 10%?Generally speaking: not really. However, if more and more UE's report CQI significantly higher than 20%, e.g. 30% then the network efficiency and overall network throughput suffers. As long as the CQI reporting is for a BLER between 10% to 20% BLER I see not real issue. Of course, reporting CQI for a BLER of 5% or only 1% BLER is not good either for UE's individual throughput and neither for the overall system throughput. "The NodeB would be then too anxious to go for high Blocksizes and is not trying its luck over air".You must be aware that the NodeB Scheduler may always attend the UE promising the highest throughput with its CQI. So in the field such "cheating" UE's may get served more often despite their high BLER.This can be partially mitigated when the Scheduler uses the ACK/NACK ratio as an additional weighting when selecting the UE's for 2ms HS-DSCH transmisson. For example if the NodeB targets a 10%BLER of ACK/NACK based on first transmission, then a good performing UE will get the max Ack/Nack weight of 9/9 (=100%) <=> 90% success rate is the target of the NodeB if 10% BLER is set. A "cheating UE" with a high BLER of e.g. 30% only achievs a 70% success Rate on first transmission, so the scheduler weight for such an UE would be reduced by a factor of 7/9. However,from my experience, the most important scheduler input is always the indicated Blocksize from the CQI report. All the big operators use a so called Proportional Fair Scheduler in NodeB: The higher the Blocksize is (indicated by CQI), the higher the priority of such an UE to get served by the NodeB. The correction imposed by the Ack/Nack ratio is most of the time not so effective implemented so a cheating UEs might be still served more 2ms TTI Intervals than a correct performing/ CQI reporting UE.

- 40 -


- 41 -


Cell Breathing due to HSDPACell Breathing due to HSDPA

• Scanner CPICH RSCP versus CPICH Ec/No with different CPICH power (27.5 dBm or 29.5 dBm) and different HSDPA MPO (6 or 7.5)

• MPO = Measurement Power Offset sent to UE via e.g. Radio Bearer Setup in order to inform UE about the “imaginary HS-DSCH Power” to be used for CQI reporting.

CQI distribution

0.000

0.100

0.200

0.300

0.400

0.500

0.600

0.700

0.800

0.900

1.000

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

CQI

CD

F

CDF (27.5|15)

CDF (27.5|12)

CDF (29.5|12)

CDF (29.5|15)

- 42 -


CPICH variation versus MPO variationCPICH variation versus MPO variation

- 43 -


CPICH variation versus MPO variationCPICH variation versus MPO variationIt is shown that increasing the CPICH power leads to better CQI when e.g. comparing 27.5|12 to 29.5|12 showing lower CQI values.But Session Throughput shows an improvement.

- 44 -


Session Throughput versus CPICH Power and MPO Session Throughput versus CPICH Power and MPO

- 45 -


Session Throughput versus CPICH Power and MPOSession Throughput versus CPICH Power and MPO

- 46 -


Application Throughput vs. CPICH Power and MPOApplication Throughput vs. CPICH Power and MPO

- 47 -


Application Throughput vs. CPICH Power and MPOApplication Throughput vs. CPICH Power and MPO

Average Ec/No

-11.00

-10.00

-9.00

-8.00

-7.00

-6.00

-5.00

-4.00

-3.00

-2.00

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

CQI

Ec/

No

AVG Ec/No (27.5|15)

AVG Ec/No (27.5|12)

AVG Ec/No (29.5|12)

AVG Ec/No (29.5|15)

- 48 -


CQI versus Ec/NoCQI versus Ec/No

- 49 -


CQI versus Ec/NoCQI versus Ec/No

- 50 -


Can 15 HS-PDSCH’s be really allocated? Considering DownlinkCan 15 HS-PDSCH’s be really allocated? Considering Downlink HS-SCCH and E-XXCH’sHS-SCCH and E-XXCH’s

SF of Common Channels: P-CPICH: 256,0; P-CCPCH: 256,1; AICH: 256,2, PICH: 256,3; S-CCPCH-1 (PCH): 128,2; S-CCPCH-2 (FACH1, FACH2): 64,1

- 51 -


Can 15 HS-PDSCH’s Codes be really allocated?Can 15 HS-PDSCH’s Codes be really allocated?

Please add the Channel Names to the marked / occupied spreading codes!

- 52 -


Solutions to the Problem of Code ShortageSolutions to the Problem of Code Shortage

• Introduce 2nd UMTS Frequency: only HSxPA allowed UE Differentiation

F1 used for Idle Mode and Rel. 99; F2 is HSDPA preferred Frequency Layer

Possible Load Balancing between F1 and F2 IFHO

• F-DPCH in Rel. 6: however not realistic mandatory in Rel. 7

o F-DPCH allows to support up to 10 users with 1 x SF256

However SHO overhead and Erlang B Blocking reduces the amount by at least 30%

o F-DPCH requires DCCH to be mapped on HS-DSCH 2nd MAC-d Flow

- 53 -


Solutions to the Problem of Code ShortageSolutions to the Problem of Code ShortagePlease be advised the 2nd frequency does not solve the issue of code shortage for the A-DCH (associated DCH) and HS-SCCH, however code shortage between Rel. 99 and downlink HS-XXXCH’s could be partially mitigated. In order to optimize the OVSF codes in a flexible manner a flexible/dynamic code assignment strategy could be introduced on networks with only one frequency layer.

Introduce 2nd UMTS FrequencyThe commonly wide spread 1+1+1 (3 sectorized NodeB) configuration can be expanded to 2+2+2 where on both frequency layers 3 concentric sectors are deployed. The handover among the concentric cells can be done blindly without the need for compressed mode (CM). Of course the addition of another frequency layer is only justified in hot spot areas and must go along also with the upgrade of Iub capacity.

• F1 used for Idle Mode and Rel. 99; F2 is HSDPA preferred Frequency LayerTo enforce camping of all UE’s being in RRC Idle state on F1, there are two possibilities. First possibility is to work with negative Q-Offset-S-N for CPICH-RSCP and CPICH_Ec/No on F2. In order not to affect the reselection between cells on F1, the parameter Q-Hyst-S should be not used for this. The alternative is to work with hierarchical cell structure. The important F1 layer gets a high priority value assigned and the least important layer to camp on (F2) gets a low priority value assigned. Then it has to be ensured that the H-criterion on F1 is always fulfilled and never fulfilled on F2 so the UE is disregarding the cells on F2 from HCS reselection.

• Possible Load Balancing between F1 and F2 IFHOF-DPCH in Rel. 6

• F-DPCH allows to support up to 10 users with 1 x SF256 but is only available in Rel. 7 (as in Rel. 6 it is quasi optional)• Requires DCCH to be mapped on HS-DSCH

- 54 -


Dynamic Code Tree Allocation between R99 and HS-PDSCHsDynamic Code Tree Allocation between R99 and HS-PDSCHs

- 55 -


Dynamic Code Tree Allocation between R99 and HS-PDSCHsDynamic Code Tree Allocation between R99 and HS-PDSCHsSemi Dynamic Code Tree AllocationSemi DCA determines the utilization of R99 codes within an update period. The result is analyzed and the share of available codes for both, R99 and HSDPA will be fixed for the next update period. The number of R99 codes might be increased, decreased or kept. Consequently the number of HSDPA codes also needs to be set accordingly.

Dynamic Code Tree AllocationCRNC uses the Physical Shared Channel Reconfiguration message to update the SF16 codes in the NodeB based on R99 DCH Channel Establishment and/or Release in conjunction with a timer. Note that the timer is optional. Upon every R99 Bearer Setup, the CRNC’s Admission Control checks if sufficient code resource is available. This logic is usually followed as priority lies on R99 when HSDPA and legacy traffic share the same frequency on F1. If a second carrier is deployed for HSDPA and HSUPA, then DCA is not necessary/vital as R99 services get setup on F1.

CRNC Node B PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST

PHYSICAL SHARED CHANNEL RECONFIGURATION RESPONSE

- 56 -


Physical Shared Channel ReconfigurationPhysical Shared Channel Reconfiguration

- 57 -


Physical Shared Channel ReconfigurationPhysical Shared Channel Reconfiguration

- 58 -


HSDPA Category Table and IR LimitationsHSDPA Category Table and IR Limitations

- 59 -


HSDPA Category Table and IR LimitationsHSDPA Category Table and IR Limitations

- 60 -


IR Memory and Stop & Wait MachinesIR Memory and Stop & Wait Machines

-5

0

5

10

15

20

25

30

0 5 10 15 20 25 30 35

SNR (dB) vs. CQISNR (dB) = Sum of symbol SNR's required for PER=0.1

1 dB Steps (=-3.5+CQI (dB))Simulated CQI Table

SN

R (d

B)(S

um o

f per

cod

e sy

mbo

l SN

R)

CQI

- 61 -


CQI DetailsCQI Details

- 62 -


CQI DetailsCQI DetailsNote that a UE may, regardless of its capabilities, report any CQI in the range of 0 to 30. Furthermore, the use of an HS-PDSCH power reduction factor for the highest CQI’s for 5 and 10 code UEs does not necessarily imply that the Node B has to adjust its transmission power.The CQI table was constructed in part using the single-transmission AWGN PER simulation performance data shown in [6] and [7]. Note that the horizontal axis is expressed as the sum of the HS-PDSCH despreader output SNR’s (or “total SNR”), summed over the number of HS-PDSCH codes defined by the CQI table. For example, the simulated SNR at PER=0.1 for CQI=14 (a 5-code CQI) is approximately 10.6dB (), which implies that the simulated per-symbol (QPSK) SNR at each HS-PDSCH despreader output was 10.6-10log(5)=3.6dB.A fixed PER value of 0.1 was selected on the basis that individual CQI PER curves were too “steep” to justify variation in PER (i.e. little additional UE performance data would have resulted), and that signaling that parameter was unnecessary. The entries in tables 1-3 were selectedto provide approximately 1dB resolution in total SNR (assuming an AWGN channel), and maintain a roughly linear relationship in total SNR as a function of CQI. This is shown in which plots the total SNR required to achieve PER=0.1 from and , along with the equation 4.5SNR CQI= − + where CQI is expressed in dB.to permit variation in the number of HS-PDSCH physical codes embedded in the CQI table (which now varies from 1-15), as well as modulation type.

- 63 -


CQI mapping table for UE Categories 1-6, 7-8, 9 and 10CQI mapping table for UE Categories 1-6, 7-8, 9 and 10

- 64 -


CQI mapping table for UE Categories 1-6, 7-8, 9 and 10CQI mapping table for UE Categories 1-6, 7-8, 9 and 10Reference Power Offset – the UE derives the CQI based on a received HS-PDSCH power level defined by a power offset Γ with respect to the CPICH power level observed by the UE. That is, if the received P/S-CPICH power is CPICHP , then the UE should report the CQI consistent with a total received HS-

PDSCH power of HSPDSCH CPICHP P= + Γ (in dB). If S-CPICH is used as a phase reference, the power offset is with respect to the S-CPCICH used by the UE, otherwise the P-CIPCH is the reference. The power offset Γ is signaled to the UE using higher layer signaling.CQI Definition – when a UE reports a particular CQI, it is reporting that for the current radio conditions, the UE is able to receive data with a transport format corresponding to the reported CQI, and lower CQI's, at single-transmission PER no greater than 0.1, given the total received power level on the HS-PDSCH implied by the reference power offset Γ from the observed received P/S-CPICH power level.Note that if – for the current radio conditions and value of Γ – the UE cannot support the minimum CQI (CQI=1) at PER=0.1, then the UE reports CQI=0 which indicates an “Out of range” (OOR) condition to the Node B.To ensure that no UE indicates a transport format exceeding its capabilities, a HS-PDSCH power reduction factor ∆ is used to indicate radio conditions beyond the highest transport format. The HS-PDSCH power reduction factor ∆ should be interpreted such that the UE is able to receive data with the highest supported transport format (corresponding to CQI 22 and 25 for 5- and 10-code UEs, respectively) assuming HS PDSCH CPICHP P− = + Γ + ∆ . Note that ∆ does not apply to CQI’s below 23 and 26 for 5-code and 10-code UE’s, respectively. For 15-code UEs, ∆ does not apply for all CQI values. As an example, CQI 23 for a 5-code UE indicates that the UE can fulfill the PER requirements using the same reference transport format as CQI 22, but with 1 dB lower received HS-PDSCH power than CQI 22.

- 65 -


HSDPA during Compressed Mode OperationHSDPA during Compressed Mode Operation

- 66 -


HSDPA during Compressed Mode OperationHSDPA during Compressed Mode OperationThe figure shows HSDPA operation during DPCH compressed mode. For simplicity reasons, the transmission gap is for uplink and downlink the same and a double gap is depicted.Compressed mode is e.g. always activated by SRNC when the associated DPCH of HSDPA carries an AMR speech call and an event 2D (bad FDD coverage) was reported by UE. Another possibility is to let the UE search for the second or third FDD frequency Interfrequency HO.

During compressed mode on the associated DPCH, the following applies for the UE for transmission of HS-DPCCH and reception of HS-SCCH and HS-PDSCH:1. The UE neglects a HS-SCCH or HS-PDSCH transmission, if a part of the HS-SCCH or a part of the corresponding HS-PDSCH overlaps with a downlink

transmission gap on the associated DPCH. In this case, neither ACK, nor NACK is transmitted by the UE to respond to the corresponding downlink transmission.

2. If a part of a HS-DPCCH slot allocated for ACK/NACK information overlaps with an uplink transmission gap on the associated DPCH, the UE does not transmit ACK/NACK information in that slot.

3. If in a HS-DPCCH sub-frame a part of the slots allocated for CQI information overlaps with an uplink transmission gap on the associated DPCH, the UE does not transmit CQI information in that sub-frame.

4. If a CQI report is scheduled in the current CQI field (as shown on page 103) and the corresponding 3-slot reference period (as shown on page 95) wholly or partly overlaps a downlink transmission gap, then the UE should use DTX in the current CQI field and in the CQI fields in the next (N_cqi_transmit –1) subframes.

Summary: DPCH compressed mode has priority over HSDPA operation.

[3GTS 25.214 (6A .3)]

- 67 -


(1) Inter Frequency Handover – Event 2D(1) Inter Frequency Handover – Event 2D

- 68 -


(1) Inter Frequency Handover – Event 2D(1) Inter Frequency Handover – Event 2D

- 69 -


(2) Inter Frequency Handover – Compressed Mode Parameter(2) Inter Frequency Handover – Compressed Mode Parameter

- 70 -



- 71 -



- 72 -



- 73 -


RRC Messages to configure and reconfigure HSDPARRC Messages to configure and reconfigure HSDPA

• Radio Bearer Setup

• Radio Bearer Release

• Radio Bearer Reconfiguration

• Cell Update Confirm

• Transport Channel Reconfiguration

• Physical Channel Reconfiguration

- 74 -


RRC Messages to configure and reconfigure HSDPARRC Messages to configure and reconfigure HSDPARadio Bearer Setup: this procedure establishes a new radio bearer. The establishment includes, based on QoS, assignment of RLC parameters, multiplexing priority for the DTCH, scheduling priority for DCH, TFS for DCH and update of TFCS. It may also include assignment of a physical channel(s) and change of the used transport channel types / RRC state.

Radio Bearer Release: this procedure releases a radio bearer. The RLC entity for the radio bearer is released. The procedure may also release a DCH, which affects the TFCS. It may include release of physical channel(s) and change of the used transport channel types / RRC state.

Radio Bearer Reconfiguration: this procedure reconfigures parameters for a radio bearer (e.g. the signalling link) to reflect a change in QoS. It may include change of RLC parameters, change of multiplexing priority for DTCH/DCCH, change of DCH scheduling priority, change of TFS for DCH, change of TFCS, assignment or release of physical channel(s) and change of used transport channel types.

Cell Update ConfirmTransport Channel Reconfiguration: this procedure reconfigures parameters related to a transport channel such as the TFS. The procedure also assigns a TFCS and may change physical channel parameters to reflect a reconfiguration of a transport channel in use.

Physical Channel Reconfiguration: may assign or release a physical channel for the UE (which may result in transport channel type switching);- may make a combined release and assignment (replacement) of a physical channel in use (which does not result in transport channel type switching / change of RRC state);- affects mainly L1, and only the transport channel type switching part of MAC;- the transport format sets (TFS and TFCS) are not assigned by this type of procedure. However, the UE can be directed to a transport channel, which TFS is already assigned to the UE.this procedure may assign, replace or release a set of physical channels used by an UE. As a result of this, it may also change the used transport channel type (RRC state). For example, when the first physical channel is assigned the UE enters the DCH/DCH state. When the last physical channel is released the UE leaves the CELL_DCH state and enters a state (and transport channel type) indicated by the network. A special case of using this procedure is to change the DL channelisation code of a dedicated physical channel.[3GTS 25.303 (5.3)]

- 75 -


(1) HSDPA Key Features & Key differences from WCDMA(1) HSDPA Key Features & Key differences from WCDMA

• HSDPA designed to operate near a 10% packet error rate (depending on NodeB vendor, also 20% could be targeted)

• 10% PER is feasible because of highly efficient MAC-hs scheduling (e.g. Proportional Fair scheduler) in NodeB rather than in RNC

o 2 ms Scheduling can respond to instantaneous UE conditions

o NACK’ed packets can be retransmitted within 12 ms ( minimum HARQ-RTT)

- 76 -



Intentionally left blankIntentionally left blank

- 77 -



• Existing Rel. 99 packet data transmission is quite different to HSDPA

o much longer retransmission latency ~ 100 ms depending TTI and on RLC-AM configuration ( Polling and Status)

o DCH favors lower BLER at around 1 % due to high retransmission latency

o more power is required to overcome interference in order to maintain a BLER of e.g. 1%

- 78 -




- 79 -


(3)

- 80 -


(3) HSDPA Key Features & Why HSDPA Throughput is (3) HSDPA Key Features & Why HSDPA Throughput is not guaranteednot guaranteed


- 81 -


(4)

- 82 -


(4) HSDPA Key Features & Why HSDPA Throughput is not(4) HSDPA Key Features & Why HSDPA Throughput is not guaranteedguaranteed


HS-DSCH Interval

HS-DSCH Credits (cont)

Maximum MAC-d PDU Length

Maximum MAC-d PDU Length (cont)

HS-DSCH Credits

HS-DSCH Repetition Period

CmCH -PI Spare

bits 7-6

0 7

Spare Extension

HS-DSCH Credits

Congestion Status

- 83 -


CAPACITY ALLOCATION payload structureCAPACITY ALLOCATION payload structure

DOCUMENTTYPE

TypeUnitOrDepartmentHereTypeYourNameHere TypeDateHere

Node B CRNC

CAPACITY ALLOCATION

- 84 -


CAPACITY ALLOCATION payload structureCAPACITY ALLOCATION payload structureThe CAPACITY ALLOCATION Control Frame describes an allocation that the SRNC may use. When the HS-DSCH Credits IE has a value of 0 it signifies that there is no resources allocated for transmission and to thus stop transmission. When the HS-DSCH Credits IE has a value of 2047, it signifies unlimited capacity for transmission of PDUs. When the HS-DSCH Repetition Period IE has a value of 0, it signifies that the allocation (Maximum MAC-d PDU Length, HS-DSCH Credits and HS-DSCH Interval IEs) can be repeated without limit. In addition to this the CAPACITY ALLOCATION Control Frame informs the RNC about the detection of congestion in the DL transport network layer with the Congestion Status Bits.

Common Transport Channel Priority Indicator (CmCH-PI)CmCH-PI, configured via the Scheduling Priority Indicator in NBAP [6], is the relative priority of the data frame and the SDUs included.Value range: {0-15, where 0=lowest priority, 15=highest priority}. Field length: 4 bits.MAC-d PDU LengthThe value of that field indicates the length of every MAC-d PDU in the payload of the HS-DSCH DATA FRAME in number of bits.Value range: {0-5000}. Field Length: 13 bits.HS-DSCH CreditsThe HS-DSCH Credits IE indicates the number of MAC-d PDUs that a CRNC may transmit during one HS-DSCH Interval granted in the HS-DSCH CAPACITY ALLOCATION Control Frame. Value range: {0-2047, where 0=stop transmission, 2047=unlimited}. Field length: 11 bits.HS-DSCH IntervalThe value of this field indicates the time interval during which the HS-DSCH Credits granted in the HS-DSCH CAPACITY ALLOCATION Control Frame may be used. The first interval starts immediately after reception of the HS-DSCH CAPACITY ALLOCATION Control Frame, subsequent intervals start immediately after the previous interval has elapsed. This value is only applied to the HS-DSCH transport channel.Value range: {0-2550 ms}. Value 0 shall be interpreted that none of the credits shall be used. Granularity: 10ms. Field Length: 8 bits.HS-DSCH Repetition PeriodDescription: The value of this field indicates the number of subsequent intervals that the HS-DSCH Credits IE granted in the HS-DSCH CAPACITY ALLOCATION Control Frame may be used. These values represent an integer number of Intervals (see subclause 6.3.3.11.4). This field is only applied to the HS-DSCH transport channel.Value range: {0-255, where 0= unlimited repetition period}. Field Length: 8 bits. Spare ExtensionIndicates the location where new IEs can in the future be added in a backward compatible way.Field length: 0-32 octets.[3GTS 25.435 (5.10)]

- 85 -


HS-DSCH Capacity Allocation Control Frame in UplinkHS-DSCH Capacity Allocation Control Frame in Uplink

(2)

656 bit long MAC-d PDU 16 bits RLC-Header with 640 payloadNote that here only DTCH is mapped on HS-DSCH

153 * 656 bits long MAC-d PDUs are allowed to be sent by RNC every 10 ms 153 * 640 bits / 10 ms = 9.792 Mbit/s offered throughput to RLC-AM

Interval = 10 msRepetition Period = endless every 10 ms 153 MAC-d PDUs of size 656 bits can be sent by RNC

Common TrCH Priority Indicator Priority of DTCH

- 86 -


HS-DSCH Capacity Allocation Frame in UplinkHS-DSCH Capacity Allocation Frame in UplinkHS-DSCH Capacity Allocation procedure is generated within the NodeB. It may be generated either in response to a HS-DSCH Capacity Request or at any other time. The NodeB may use this message to modify the capacity at any time, irrespective of the reported user buffer status in RNC’s HS-DSCH user data frame or RNC’s Capacity Allocoation Request frame. The HS-DSCH CAPACITY ALLOCATION frame is used by the NodeB to control the user data flow. HS-DSCH Credits IE indicates the number of MAC-d PDUs that the CRNC is allowed to transmit for the MAC-d flow and the associated priority level indicated by the Common Transport Channel Priority Indicator IE. The Maximum MAC- d PDU length, HS-DSCH Credits, HS-DSCH Interval and HS-DSCH Repetition Period IEs indicates the total amount of capacity granted. Any capacity previously granted is replaced. If HS-DSCH Credits IE = 0 (e.g. due to congestion in the Node B), the CRNC shall immediately stop transmission of MAC-d PDUs. If HS-DSCH Credits IE = 2047, the CRNC can transmit MAC-d PDUs with unlimited capacity. The IEs used in the HS-DSCH CAPACITY ALLOCATION Control Frame are the Common Transport Channel Priority Indicator, HS-DSCH Credits, Maximum MAC- d PDU Length, HS-DSCH Interval and the HS-DSCH Repetition Period. If the HS-DSCH Repetition Period IE = 0 "unlimited repetition period" it indicates that the CRNC may transmit the specified number of MAC-d PDUs for an unlimited period according to the bounds of Maximum MAC-d PDU Length, HS-DSCH Credits and HS-DSCH Interval IEs.

Congestion StatusThe Congestion Status Bits are used by the NodeB to indicate whether a congestion situation is detected in a DL transport network layer or not. The NodeB provides the congestion status in every HS-DSCH CAPACITY ALLOCATION Control Frame, which the CRNC may use.0 No TNL Congestion1 Reserved for future use2 TNL Congestion – detected by delay build-up3 TNL Congestion – detected by frame loss[3GTS 25.435 (5.10, 6.3.3.11)]

- 87 -


HS-DSCH Capacity Request procedureHS-DSCH Capacity Request procedure

Node B CRNC

CAPACITY REQUEST

1

User Buffer Size

User Buffer Size ( cont)

CmCH -PI Spare bits 7-4

Spare Extension

Payload

1

0-32

1

Number of Octets

7 0

Note: Depending on Vendor, if the SRNC has user data received from Iu-ps but no valid Capacity Allocation received from NodeB, then the SRNC can enforce a Capacity Allocation. Additionally the SRNC can emphasize the amount of user data being currently buffered per priority indicator (CmCH-PI) in order to get better Capacity Allocation from NodeB

- 88 -


HS-DSCH Capacity Request procedureHS-DSCH Capacity Request procedureHS-DSCH Capacity Request is sent for each priority group to indicate the user buffer size. The control frame is sent by the HS-DSCH CAPACITY REQUEST is sent for each priority group to indicate the user buffer size. The control frame is sent by the SRNC when the SRNC considers the user buffer status needs an increased buffer reporting frequency. This may be sent to signal an event, such as, data arrival or user-buffer discard. This control frame is used to improve user-buffer reporting above the level produced by the user-buffer reporting associated with the HS-DSCH DATA FRAMEs.

Common Transport Channel Priority Indicator (CmCH-PI)CmCH-PI, configured via the Scheduling Priority Indicator in NBAP [6], is the relative priority of the data frame and the SDUs included.Value range: {0-15, where 0=lowest priority, 15=highest priority}.Field length: 4 bits.

User Buffer Size in BytesIndicates the users' buffer size (i.e. the amount of data in the buffer) in octets for a given Common Transport Channel Priority Indicator level.Value range: {0-65535} [Bytes].Field length: 16 bits.

Spare ExtensionIndicates the location where new IEs can in the future be added in a backward compatible way.Field length: 0-32 octets.

Note that the Capacity Request frame is optional to be supported and can be partial replaced by the NodeB’s Initial Capacity Allocation[3GTS 25.435 (6.3.3.10)]

- 89 -


NodeB’s Initial Capacity Allocation in e.g. RL SetupNodeB’s Initial Capacity Allocation in e.g. RL Setup

- 90 -


NodeB’s Initial Capacity Allocation in e.g. RL SetupNodeB’s Initial Capacity Allocation in e.g. RL SetupThe HS-DSCH Initial Capacity Allocation IE provides flow control information for each scheduling priority class for the HS-DSCH FP over Iub.

HS-DSCH Initial Window SizeIndicates the initial number of MAC-d PDUs that may be transmitted before new credits are received from the NodeB.

IE/Group Name IE Type and Reference

Semantics Description

HS-DSCH Initial Window Size INTEGER (1..255) Number of MAC-d PDUs

Note: The SRNC can transmit one time 8 * MAC-d PDU’s with size 656 bits then the SRNC must wait for a Capacity Allocation from NodeB.

MAC-d PDU SizeThe MAC-d PDU Size provides the size in bits of the MAC-d PDU.



MAC-d PDU Size INTEGER (1..5000,…)

Scheduling Priority IndicatorIndicates the relative priority of the HS-DSCH [FDD - or E-DCH data frame]. Used by the Node B when scheduling HS-DSCH[FDD - or E-DCH].



Scheduling Priority Indicator INTEGER (0..15) Relative priority of the HS-DSCH [FDD - or E-DCH data frame]:"0" =Lowest Priority…"15" =Highest Priority

[3GTS 25.433 (9.2.1.31Ha)]

- 91 -


SRNC sends only 8 MAC-d PDU’s and waits for NodeB’s SRNC sends only 8 MAC-d PDU’s and waits for NodeB’s HS-DSCH Capacity AllcoationHS-DSCH Capacity Allcoation

- 92 -


SRNC sends only 8 MAC-d PDU’s and waits for NodeB’s SRNC sends only 8 MAC-d PDU’s and waits for NodeB’s HS-DSCH Capacity AllcoationHS-DSCH Capacity AllcoationThe picture above shows that after the SRNC has transmitted 7 +1 MAC-d PDU’s via 2 HS-DSCH Data frames, the NodeB responds with Capacity Allcation and informs the SRNC that it is allowed to transmit 153 * 656 bits MAC-d PDU’s every 10 ms endless.It can be assumed that the CQI reported by the UE is extremely good and that therefore the NodeB permits such a high Capacity Allocation. Note that a Cat 8 UE with 7.2 Mbit/s throughput on MAC-hs layer was used in the test lab. The UE has extreme good radio conditions.

- 93 -


HS-DSCH Data Transfer procedureHS-DSCH Data Transfer procedure

CRNCNode B

HS-DSCH DATA FRAME

Header CRC FT

CmCH-PI Frame Seq Nr

MAC-d PDU Length MAC-d PDU Length (cont) Spare 1-0

Num Of PDUs

User Buffer Size

User Buffer Size (cont)

Spare, bits 7-4 MAC-d PDU 1

MAC-d PDU 1 (cont) Pad

Header

Spare, bits 7-4 MAC-d PDU n

MAC-d PDU n (cont) Pad Payload

New IE Flags 7(E) 6 5 4 3 2 1 0

Spare Extension

Payload CRC (cont)

DRT

DRT (cont)

7 0

Payload CRC

Flush

The New IE Flags IE is only present if at least one new IE is present.

- 94 -


HS-DSCH Data Transfer procedureHS-DSCH Data Transfer procedureThe Data Transfer procedure is used to transfer a HS-DSCH DATA FRAME from the CRNC to a NodeB. When the CRNC has been granted capacity by the NodeB via the HS-DSCH CAPACITY ALLOCATION Control Frame or via the HS-DSCH initial capacity allocation via NBAP RL Setup Response or Synchronized RL Reconfiguration Preparation Response and the CRNC has data waiting to be sent, then the HS-DSCH DATA FRAME is used to transfer the data. If the CRNC has been granted capacity by the NodeB via the HS-DSCH initial capacity allocation, this capacity is valid for only the first HS-DSCH DATA FRAME transmission. When data is waiting to be transferred, and a CAPACITY ALLOCATION is received, a DATA FRAME will be transmitted immediately according to allocation received. Multiple MAC-d PDUs of same length and same priority level (CmCH-PI) may be transmitted in one MAC-d flow in the same HS-DSCH DATA FRAME. The HS-DSCH DATA FRAME includes a User Buffer Size IE to indicate the amount of data pending for the respective MAC-d flow for the indicated priority level. Within one priority level and size the MAC-d PDUs shall be transmitted by the Node B on the Uu interface in the same order as they were received from the CRNC.If the Flush IE in the HS-DSCH DATA FRAME is set to "flush" the NodeB should remove all MAC-d PDUs from the corresponding MAC-hs Priority Queue that have been received prior to this data frame on the same transport bearer. This capability has been introduced in Rel. 6 to increase the efficiency of the RLC Reset procedure. If e.g. a UE triggers the RLC Reset procedure, the SRNC is required to return an Reset Acknowledgement. The UE discards all data that is received between sending an RLC Reset and receiving the Acknowledgement. Emptying the priority queue avoids sending data that will be anyway discarded in UE and helps therefore to minimize the delay associated with the UE receiving the acknowledgement RLC PDU.For the purpose of TNL Congestion Control on HSDPA, the Frame Sequence Number and the DRT IEs may be included by the CRNC.New IE FlagsBit 0 of New IE Flags in HS-DSCH DATA FRAME indicates if a DRT is present (1) or not (0) in the 2 octets following the New IE Flags IE. Bits 1 through 6 of New IE Flags in HS-DSCH DATA FRAME shall be set to 0.Field length of Spare Extension IE in HS-DSCH DATA FRAME is 0-29 octets.The New IE Flags IE is only present if at least one new IE is present. The New IE Flags IE contains flags indicating which new IEs that are present following the New IE Flags IE. The last bit position of the New IE Flags IE is used as the Extension Flag to allow the extension of the New IE Flags IE in the future. Extension octets of the New IE Flags IE shall follow directly after the first octet of the New IE Flags IE. When an extension octet of the New IE Flags IE is present, then all previous extension octets of the New IE Flags IE and the New IE Flags IE shall also be present, even if they have all their flag bits indicating no presence of their respective new IEs.Value range:Bit 0-6 of each octet: Indicates if a new IE is present (1) or not present (0) in the bytes following the New IE Flags IE. The meaning of each bit is explained in the corresponding DATA FRAME subclause;Bit 7 of each octet: Indicates if an extension octet of the New IE Flags IE follows (1) or not (0).Field length: 1 – 31 octets.

[3GTS 25.435 (5.1.6, 6.2.6A)]

- 95 -


HS-DSCH DATA FRAMEHS-DSCH DATA FRAME

per MAC-d Flow a VPI/VCI/CID is configured by RNC

Different logical channels with different priority are distinguished within the same MAC-d flow by the CmCh-PI parameter

Protocol Tracer decodes the individual 7 Mac-d PDU’s and is even able to reassemble the IP-frame

- 96 -


HS-DSCH DATA FRAMEHS-DSCH DATA FRAMERNC sends 7 MAC-d PDU’s each having the same length of 656 bits (which is a must within the same HS-DSCH data frame). At the moment of sending the SRNC buffer occupancy for CmCH-PI = 3 was 1643 bytes. Thus the SRNC leaked its bucked by 7 x 656 bits 7 x 640 bits = 560 bytes. Note that the RLC-AM header of 16 bits cannot be counted for emptying the SRNC buffer.

Flush (Rel. 6 enhancement)Indicates whether the DRNS should remove (1) or not (0) all the MAC-d PDUs from the corresponding MAC-hs Priority Queue that have been received prior to this data frame HS-DSCH DATA FRAME on the same transport bearer.Value range: {0 = no flush, 1 = flush}. Field Length: 1 bit.

DRT (Delay Reference Time) (Rel. 6 enhancement) – not used here as optionalDRT is a 16-bit Delay Reference Time. DRT can be used for dynamic delay measurements. The DRT counter bridges the same time span as RFN and BFN. DRT is locked to RFN in SRNC and is a 40960 counter with 1 ms resolution.Value range: {0..40959DEC ms (0..9FFFHEX ms)}. Granularity: 1 ms. Field length: 16 bits.

Note: The DRT could be used for the purpose of detecting inceased delay possibly resulting from Iub congestion.

Frame Sequence NumberDescription: The 4-bit Frame Sequence Number is incremented for each transmitted HS DSCH data frame belonging to one MAC-d flow. At wraparound of the Frame Sequence Number, the value "0" shall not be used. Each flow generates its own Frame Sequence.Value range: 0 is a special value and indicates that the Frame Sequence Number IE shall be treated as spare.

1 – 15indicates the Frame Sequence Number.Granularity: 1.Field length: 4 bits.

[3GTS 25.435 (6.2.7)]

- 97 -


- 98 -


Simplified Iub Flow Control descriptionSimplified Iub Flow Control description


- 99 -


(1)

- 100 -


(1) Using UTRAN Data to understand HSDPA(1) Using UTRAN Data to understand HSDPA


- 101 -


(2)

- 102 -


(2) Using UTRAN Data to understand HSDPA(2) Using UTRAN Data to understand HSDPA


- 103 -


(1)

- 104 -


(1) Understanding Flow Control Flow Control over HSDPA(1) Understanding Flow Control Flow Control over HSDPA


- 105 -


(2)

- 106 -




- 107 -


(3)

- 108 -




- 109 -


0

2000

4000

6000

8000

10000

12000

14000

160003:

31:4

5.12

3:31

:45.

983:

31:4

6.85

3:31

:47.

713:

31:4

8.58

3:31

:49.

443:

31:5

0.30

3:31

:51.

173:

31:5

2.03

3:31

:52.

903:

31:5

3.76

3:31

:54.

623:

31:5

5.49

3:31

:56.

353:

31:5

7.22

3:31

:58.

083:

31:5

8.94

3:31

:59.

813:

32:0

0.67

3:32

:01.

543:

32:0

2.40

3:32

:03.

263:

32:0

4.13

3:32

:04.

993:

32:0

5.86

3:32

:06.

723:

32:0

7.58

3:32

:08.

453:

32:0

9.31

3:32

:10.

183:

32:1

1.04

3:32

:11.

903:

32:1

2.77

3:32

:13.

633:

32:1

4.50

3:32

:15.

363:

32:1

6.22

3:32

:17.

093:

32:1

7.95

3:32

:18.

823:

32:1

9.68

3:32

:20.

543:

32:2

1.41

3:32

:22.

273:

32:2

3.14

3:32

:24.

003:

32:2

4.86

3:32

:25.

733:

32:2

6.59

3:32

:27.

463:

32:2

8.32

3:32

:29.

183:

32:3

0.05

3:32

:30.

913:

32:3

1.78

3:32

:32.

643:

32:3

3.50

3:32

:34.

373:

32:3

5.23

3:32

:36.

103:

32:3

6.96

3:32

:37.

823:

32:3

8.69

3:32

:39.

553:

32:4

0.42

3:32

:41.

283:

32:4

2.14

3:32

:43.

013:

32:4

3.87

3:32

:44.

743:

32:4

5.60

3:32

:46.

463:

32:4

7.33

3:32

:48.

193:

32:4

9.06

3:32

:49.

923:

32:5

0.78

3:32

:51.

653:

32:5

2.51

3:32

:53.

38

CREDITS [Bytes / 10ms] TRANSMITTED Bytes per 10 ms FP: User Buffer Size

- 110 -


Example of HTTP download – 10 times the same WebpageExample of HTTP download – 10 times the same WebpageTest Setup:The above picture was obtained in an extreme good radio environment. The UE was a Cat 8 HS-DSCH physical layer category and so capable of receiving up to 7.2 Mbit/s.The same Web-page was downloaded 10 times with 1s break in between. Above it can be seen that there are 9 even gaps of 1s length. However the download was not always evenly fast. Some page-download took longer (e.g. the 1st one or the last one). Especially the last Web-page download shows a long interruption time in between (more than 1s).Objective:The goal was to see how the MAC-hs scheduler advertises the credits once there are user data in SRNC available. It was also interesting to see what amount of credits the NodeB would send to RNC and how does the SRNC’s buffer occupancy increase / decrease over time when the UE downloads with nearly 7 Mbit/s.Analysis:The NodeB has advertised an initial amount of credits via the NBAB Radio Link Setup Response message ( UE changed from CELL_FACH to CELL_DCH) of 8 * 656 bits only. Note that 656 bits RLC-AM PDU size are used instead of 336 bits in order to avoid stalling in SRNC once the user data rate exceeds 5 Mbit/s. Too small RLC-AM PDU of 336 bits cannot sustain the throughput rates higher than 5 Mbit/s.In the lab the throughput conditions are extremely good therefore the NodeB only advertises two kinds of Capacity Allocations: A) 5 * 656 bits within 80 ms and endless repetitionB) 153 * 656 bits within 10 ms and endless repetition⇒ In case of A) this corresponds to a user data rate of 5 * (656 – 16) / 80 ms = 40 kbit/s⇒ In case of B) this corresponds to a user data rate of 153 * (656 – 16) / 10 ms = 9.792 Mbit/sIt can be noticed that the User Buffer size in SRNC shoots above the allocated credits and also the Transmitted Bytes in downlink within HS-DSCH HS-DSCH data frame exceeds the credit allocation. This can be explained in the following: We use NodeB’s HS-DSCH CTRL frame “Capacity Allocation” as the time reference for counting the bytes in 10 ms bins of User Buffer Size and Transmitted Bytes. It depends however on SRNC how the 10 ms intervals with up to 153 MAC-d PDU’s are counted and delivered to NodeB. It seems that the NodeB is advertising immediately very Credits once the SRNC indicates x amount of bytes in its buffer. As the HS-DSCH throughput on Uu is quite high the NodeB is extreme quick to empty SRNC’s buffer.Next Step:As it is not clear why the downloads differ, it is therefore important to depict at the same time the TCP-acknowledgements in uplink and the TCP user data arrival in SRNC. Another graph is envisaged to show the RLC-AM transmissions, Status Reporting and retransmission.

Iub Flow Control (5xE1, dynamic DL code tree management, CAT8 UE)

0

10000

20000

30000

40000

50000

60000

107.

000

108.

000

109.

000

110.

000

111.

000

112.

000

113.

000

relative Time (s)

Byt

es /

50

ms

FP: User Buffer Size Credits[Bytes/80ms] TransmittedBytes_Bin

- 111 -


- 112 -


Flow Control of Cat 8Flow Control of Cat 8

Iub Flow Control

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

100000

12:0

4:39

.707

12:0

4:43

.496

12:0

4:43

.778

12:0

4:44

.082

12:0

4:44

.369

12:0

4:44

.725

12:0

4:45

.189

12:0

4:45

.720

12:0

4:46

.022

12:0

4:46

.282

12:0

4:46

.542

12:0

4:46

.826

12:0

4:47

.027

12:0

4:47

.220

12:0

4:47

.406

12:0

4:47

.727

12:0

4:48

.100

12:0

4:48

.598

12:0

4:48

.858

12:0

4:49

.120

12:0

4:49

.466

12:0

4:49

.639

12:0

4:49

.850

12:0

4:50

.016

12:0

4:50

.218

12:0

4:50

.780

12:0

4:50

.984

12:0

4:51

.151

12:0

4:51

.806

12:0

4:52

.066

12:0

4:52

.326

12:0

4:52

.764

12:0

4:53

.021

12:0

4:53

.576

12:0

4:53

.836

12:0

4:54

.322

12:0

4:54

.634

12:0

4:54

.890

Time

Byt

es/8

0m

s

FP: User Buffer Size Credits[Bytes/80ms] TransmittedBytes_Bin

- 113 -


based this trace one can clearly see a slow increase of credits even in a single user szenario on a 5xE1 IMA site!

- 114 -


Iub Flow ControlIub Flow Control

- 115 -


Solutions for Practical Exercises• Part 1: HSDPA Refresher• Answer:

- 116 -


HSDPA optimzation

Documents

Transcript of HSDPA optimzation