Inacon - HSDPA Network Optimization & Troubleshooting

HSDPA Network Optimization & Troubleshooting
INACON GmbH Kriegsstrasse 154 76133 Karlsruhe Germany www.inacon.com e-mail: inacon@inacon.de
Cover design by Stefan Kohler 1999 - 2008 INACON GmbH Kriegsstrasse 154 76133 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.
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)
Foreword 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 (inacon@inacon.de), 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.

Table of Contents
HSDPA in Practice......................................................12
HSDPA 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...............32 HS-PDSCH Symbol Rate.............................................................................................34 Code Rate R................................................................................................................34 HSDPA Throughput versus SIR Simulation..............................................................38
QPSK with Code Rate R .................................................................................................38 QPSK with Code Rate R .................................................................................................38 QPSK with Code Rate R .................................................................................................38 16-QAM with Code Rate R ..............................................................................................38 16-QAM with Code Rate R .............................................................................................38 HSDPA Throughput according to Antti Toskala....................................................................40
CPICH variation versus MPO variation........................................................................44 Session Throughput versus CPICH Power and MPO..................................................46 Application Throughput vs. CPICH Power and MPO....................................................48 CQI versus Ec/No........................................................................................................50 Can 15 HS-PDSCHs Codes be really allocated?........................................................52 Solutions to the Problem of Code Shortage.................................................................54
Introduce 2nd UMTS Frequency..........................................................................................54 F-DPCH in Rel. 6..................................................................................................................54 Dynamic Code Tree Allocation between R99 and HS-PDSCHs...........................................56
Semi Dynamic Code Tree Allocation............................................................................56 Dynamic Code Tree Allocation.....................................................................................56 Physical Shared Channel Reconfiguration...................................................................58 CQI mapping table for UE Categories 1-6, 7-8, 9 and 10.............................................65 HSDPA 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...................................73 Radio 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
-9-

(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
- 10 -
Intentionally left blank
- 11 -
HSDPA Troubleshooting
HSDPA in Practice
- 12 -
Objectives
After 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 configured via RRC Analyse throughput issues on Iub HS-DSCH Flow Control Review the impact of CPICH Power on CQI and MPO
- 13 -
HSDPA Channel Overview
DTCH
HS-DSCH
ACK / NACK, CQI
n x HS-PDSCHs SF 16
User Data e.g. TCP/IP frames (FTP, HTTP, SMTP, POP, )
HS-SCCH (14) SF 128

UE-id and HS-DSCH related control info
HS-DPCCH SF 256
- 14 -
HSDPA Channel Overview
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 -
Practical Exercise:
- 16 -
Please fill in the Physical Channel Names!
Answer:
- 17 -
Example of HSDPA Operation in ROMES
- 18 -
Example of HSDPA Operation in ROMES
[ROMES Drive test tool (Rohde & Schwarz)]
- 19 -
- 20 -
Example 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
- 21 -
- 22 -
(2) HSDPA various Throughput Rates
Ec/No of HS Serving Cell CQI HS Physically Requested Throughput HS Physically Scheduled Thp HS Physically Served Thp
- 23 -
- 24 -
(3) HS-DSCH Retransmission and BLER
HS-DSCH NACK Rate ~ HS-DSCH Retransmission Rate ~ HS-DSCH BLER 1st Transmission
- 25 -
- 26 -
(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
- 27 -
- 28 -
(5) HS-SCCH Decoding
HS-SCCH Decode Success Rate: shows how often the UE is scheduled
- 29 -
UTRAN SW, Backpressure = 25% 3xE1 UTRAN SW, Backpressure = 35% With TCP/IP Optimizer for Windows XP
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.
- 30 -
(6) Iub-Bandwidth Limitation or bad Flow Control between NodeB 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)
- 31 -
Throughput and Code Rate R
QPSK: 2 bits/symbol * 240 Ksymbols/s * #HS-PDSCHs 16-QAM: 4 bits/symbol * 240 Ksymbols * #HS-PDSCHs R(QPSK) = TBS / (n * 960 bits) R(16-QAM) = TBS / (n * 1920 bits)
- 32 -
Throughput and Code Rate R
Here we would like to focus on the user plane throughput and physical amount of bit to be transferred.
HS-PDSCH Symbol Rate
3.84 Mcps / (16 chips/symbol) = 240 Ksymbols/s

Number of Bits per TTI with QPSK and 16-QAM
240 Ksymbols * {2 | 4 [bits/symbols]} * 2 ms * #HS-PDSCHs

Results: QPSK: 960 bits per HS-PDSCH 16-QAM: 1920 bits per HS-PDSCH
Code Rate R
R = (Payload bits before Turbo Coding) / (Output after Turbo Coding and Rate Matching)
- 33 -
Achievable Throughput without Retransmissions
- 34 -
Achievable Throughput without Retransmissions
Max throughput = R * {2 | 4 [bits/symbol]} * 240 ksymbol/s * #HS-PDSCHs
(1) Example: QPSK with R = 3/4 and 10 HS-PDSCHs
Max 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-PDSCHs

Max throughput = 2/4 * 4 bits/symbol * 240 ksymbol/s * 10 = 4.8 Mbit/s
- 35 -
HSDPA Throughput versus SIR Simulation
- 36 -
HSDPA Throughput versus SIR Simulation
QPSK with Code Rate R
240 Ksymbols x 2 Bits/Symbol x = 120 kbit/s per HS-PDSCH


16-QAM with Code Rate R

16-QAM with Code Rate R

- 37 -
HSDPA Throughput according to Antti Toskala
- 38 -
HSDPA Throughput according to Antti Toskala
Usually 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 or less 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.
- 39 -
- 40 -
Cell 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.
- 41 -
CPICH variation versus MPO variation
CQI distribution
1.000 0.900 0.800 0.700 0.600 CDF 0.500 0.400 0.300 0.200 0.100 0.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
- 42 CDF (27.5|15) CDF (27.5|12) CDF (29.5|12) CDF (29.5|15)
CPICH variation versus MPO variation
It 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.
- 43 -
Session Throughput versus CPICH Power and MPO
- 44 -
Session Throughput versus CPICH Power and MPO
- 45 -
Application Throughput vs. CPICH Power and MPO
- 46 -
Application Throughput vs. CPICH Power and MPO
- 47 -
CQI versus Ec/No
Average Ec/No
-2.00 -3.00 -4.00 -5.00 Ec/No -6.00 -7.00 -8.00 -9.00 -10.00 -11.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
- 48 -
AVG Ec/No (27.5|15) AVG Ec/No (27.5|12) AVG Ec/No (29.5|12) AVG Ec/No (29.5|15)
CQI versus Ec/No
- 49 -
Can 15 HS-PDSCHs be really allocated? Considering Downlink HS-SCCH and E-XXCHs
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
- 50 -
Can 15 HS-PDSCHs Codes be really allocated?
Please add the Channel Names to the marked / occupied spreading codes!
- 51 -
Solutions 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

- 52 -
Solutions to the Problem of Code Shortage
Please 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-XXXCHs 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 Frequency

The 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 Layer
To enforce camping of all UEs being in RRC Idle state on F1, there are two possibilities. First possibility is to work with negative Q-Offset-S-N for CPICHRSCP 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 IFHO F-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
- 53 -
Dynamic Code Tree Allocation between R99 and HS-PDSCHs
- 54 -
Dynamic Code Tree Allocation between R99 and HS-PDSCHs
Semi Dynamic Code Tree Allocation
Semi 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 Allocation

CRNC 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 CRNCs 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.
- 55 -
Physical Shared Channel Reconfiguration
CRNC
PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST
Node B
PHYSICAL SHARED CHANNEL RECONFIGURATION RESPONSE
- 56 -
Physical Shared Channel Reconfiguration
- 57 -
HSDPA Category Table and IR Limitations
- 58 -
HSDPA Category Table and IR Limitations
- 59 -
IR Memory and Stop & Wait Machines
- 60 -
CQI Details
30 SNR (dB) (Sum of per code symbol SNR) 25 20 15 10 5 0 -5 0 5 10 15 CQI
- 61 -
SNR (dB) vs. CQI

SNR (dB) = Sum of symbol SNR's required for PER=0.1 1 dB Steps (=-3.5+CQI (dB)) Simulated CQI Table
20
25
30
35
CQI Details
Note 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 CQIs 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 SNRs (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 selected to 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 SNR = 4.5 + 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.
- 62 -
CQI mapping table for UE Categories 1-6, 7-8, 9 and 10
- 63 -
CQI mapping table for UE Categories 1-6, 7-8, 9 and 10
Reference 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 P CPICH , then the UE should report the CQI consistent with a total received HSPDSCH power of PHSPDSCH = P CPICH + (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
not apply to CQIs below 23 and 26 for 5-code and 10-code UEs, 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 HSPDSCH power than CQI 22.
PHS PDSCH = PCPICH + + . Note that does
- 64 -
HSDPA during Compressed Mode Operation
- 65 -
HSDPA during Compressed Mode Operation
The 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 HSPDSCH: 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)]
- 66 -
(1) Inter Frequency Handover Event 2D
- 67 -
(1) Inter Frequency Handover Event 2D
- 68 -
(2) Inter Frequency Handover Compressed Mode Parameter
- 69 -
- 70 -
- 71 -
- 72 -
RRC Messages to configure and reconfigure HSDPA
Radio Bearer Setup Radio Bearer Release Radio Bearer Reconfiguration Cell Update Confirm Transport Channel Reconfiguration Physical Channel Reconfiguration
- 73 -
RRC Messages to configure and reconfigure HSDPA
Radio 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 Confirm Transport 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)]
- 74 -
(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 NACKed packets can be retransmitted within 12 ms ( minimum HARQRTT)
- 75 -
- 76 -
Existing Rel. 99 packet data transmission is quite different to HSDPA o much longer retransmission latency ~ 100 ms depending TTI and on RLCAM 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%
- 77 -
- 78 -
(3)
- 79 -
(3) HSDPA Key Features & Why HSDPA Throughput is not guaranteed
- 80 -
(4)
- 81 -
(4) HSDPA Key Features & Why HSDPA Throughput is not guaranteed
- 82 -
CAPACITY ALLOCATION payload structure
0 Spare bits 7-6 Congestion Status CmCH-PI
Node B
CRNC
CAPACITY ALLOCATION
Maximum MAC-d PDU Length Maximum MAC-d PDU Length (cont) HS-DSCH Credits
HS-DSCH Credits (cont) HS-DSCH Interval HS-DSCH Repetition Period Spare Extension
- 83 -
CAPACITY ALLOCATION payload structure
The 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 Length The 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 Credits The 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 Interval The 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 Period Description: 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 Extension Indicates 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)]
- 84 -
(2)
HS-DSCH Capacity Allocation Control Frame in Uplink
Common TrCH Priority Indicator Priority of DTCH 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
656 bit long MAC-d PDU 16 bits RLC-Header with 640 payload Note that here only DTCH is mapped on HS-DSCH
Interval = 10 ms Repetition Period = endless every 10 ms 153 MAC-d PDUs of size 656 bits can be sent by RNC
- 85 -
HS-DSCH Capacity Allocation Frame in Uplink
HS-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 RNCs HS-DSCH user data frame or RNCs 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 Status The 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 Congestion 1 Reserved for future use 2 TNL Congestion detected by delay build-up 3 TNL Congestion detected by frame loss [3GTS 25.435 (5.10, 6.3.3.11)]
- 86 -
HS-DSCH Capacity Request procedure
Number of Octets 7 0
Node B
CRNC
Spare bits 7-4

CAPACITY REQUEST
CmCH-PI
1 1 Payload 1 0-32
User Buffer Size User Buffer Size (cont) Spare Extension
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
- 87 -
HS-DSCH Capacity Request procedure
HS-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 Bytes Indicates 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 Extension Indicates 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 NodeBs Initial Capacity Allocation [3GTS 25.435 (6.3.3.10)]
- 88 -
NodeBs Initial Capacity Allocation in e.g. RL Setup
- 89 -
NodeBs Initial Capacity Allocation in e.g. RL Setup
HS-DSCH Initial Window Size Indicates the initial number of MAC-d PDUs that may be transmitted before new credits are received from the NodeB.
IE/Group Name HS-DSCH Initial Window Size IE Type and Reference INTEGER (1..255) Semantics Description Number of MAC-d PDUs
The HS-DSCH Initial Capacity Allocation IE provides flow control information for each scheduling priority class for the HS-DSCH FP over Iub.
Note: The SRNC can transmit one time 8 * MAC-d PDUs with size 656 bits then the SRNC must wait for a Capacity Allocation from NodeB. MAC-d PDU Size The MAC-d PDU Size provides the size in bits of the MAC-d PDU.
IE/Group Name MAC-d PDU Size IE Type and Reference INTEGER (1..5000, ) Semantics Description
Scheduling Priority Indicator Indicates 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].
IE/Group Name Scheduling Priority Indicator IE Type and Reference INTEGER (0..15) Semantics Description 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)]
- 90 -
SRNC sends only 8 MAC-d PDUs and waits for NodeBs HS-DSCH Capacity Allcoation
- 91 -
SRNC sends only 8 MAC-d PDUs and waits for NodeBs HS-DSCH Capacity Allcoation
The picture above shows that after the SRNC has transmitted 7 +1 MAC-d PDUs 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 PDUs 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.
- 92 -
7 0 Header CRC Frame Seq Nr CmCH-PI FT
HS-DSCH Data Transfer procedure

Node B CRNC
MAC-d PDU Length

MAC-d PDU Length (cont) FlushSpare 1-0
Header
Num Of PDUs User Buffer Size
HS-DSCH DATA FRAME
User Buffer Size (cont) Spare, bits 7-4 MAC-d PDU 1 MAC-d PDU 1 (cont)
Pad
Spare, bits 7-4 MAC-d PDU n
The New IE Flags IE is only present if at least one new IE is present.
MAC-d PDU n (cont)

7(E) 6 New IE Flags 5 4 3 2 1
Pad 0
Payload
DRT DRT (cont) Spare Extension Payload CRC Payload CRC (cont)
- 93 -
HS-DSCH Data Transfer procedure
The 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 Flags Bit 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)]
- 94 -
HS-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 PDUs and is even able to reassemble the IP-frame
- 95 -
HS-DSCH DATA FRAME
RNC sends 7 MAC-d PDUs 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 optional DRT 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 Number Description: 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)]
- 96 -
- 97 -
Simplified Iub Flow Control description
- 98 -
(1)
- 99 -
(1) Using UTRAN Data to understand HSDPA
- 100 -
(2)
- 101 -
(2) Using UTRAN Data to understand HSDPA
- 102 -
(1)
- 103 -
(1) Understanding Flow Control Flow Control over HSDPA
- 104 -
(2)
- 105 -
- 106 -
(3)
- 107 -
- 108 -
10000
12000
14000
16000
2000
4000
6000
8000
0
3:31:45.12 3:31:45.98 3:31:46.85 3:31:47.71 3:31:48.58 3:31:49.44 3:31:50.30 3:31:51.17 3:31:52.03 3:31:52.90 3:31:53.76 3:31:54.62 3:31:55.49 3:31:56.35 3:31:57.22 3:31:58.08 3:31:58.94 3:31:59.81 3:32:00.67 3:32:01.54 3:32:02.40 3:32:03.26 3:32:04.13 3:32:04.99 3:32:05.86 3:32:06.72 3:32:07.58 3:32:08.45 3:32:09.31 3:32:10.18 3:32:11.04 3:32:11.90 3:32:12.77 3:32:13.63 3:32:14.50 3:32:15.36 3:32:16.22 3:32:17.09 3:32:17.95 3:32:18.82 3:32:19.68 3:32:20.54 3:32:21.41 3:32:22.27 3:32:23.14 3:32:24.00 3:32:24.86 3:32:25.73 3:32:26.59 3:32:27.46 3:32:28.32 3:32:29.18 3:32:30.05 3:32:30.91 3:32:31.78 3:32:32.64 3:32:33.50 3:32:34.37 3:32:35.23 3:32:36.10 3:32:36.96 3:32:37.82 3:32:38.69 3:32:39.55 3:32:40.42 3:32:41.28 3:32:42.14 3:32:43.01 3:32:43.87 3:32:44.74 3:32:45.60 3:32:46.46 3:32:47.33 3:32:48.19 3:32:49.06 3:32:49.92 3:32:50.78 3:32:51.65 3:32:52.51 3:32:53.38
CREDITS [Bytes / 10ms] TRANSMITTED Bytes per 10 ms FP: User Buffer Size
- 109 -
Example of HTTP download 10 times the same Webpage
Test 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 SRNCs 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 repetition B) 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/s It 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 NodeBs 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 PDUs 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 SRNCs 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.
- 110 -
Iub Flow Control (5xE1, dynamic DL code tree management, CAT8 UE)
FP: User Buffer Size 60000 Credits[Bytes/80ms] TransmittedBytes_Bin
50000
40000 Bytes / 50 ms
30000
20000
10000
0 107.000 108.000 109.000 110.000 111.000 112.000 113.000
relative Time (s)
- 111 -
Flow Control of Cat 8
- 112 -
Bytes/80ms
100000
10000
20000
30000
40000
50000
60000
70000
80000
90000
0 12:04:39.707 12:04:43.496 12:04:43.778 12:04:44.082 12:04:44.369 12:04:44.725 12:04:45.189 12:04:45.720 12:04:46.022 12:04:46.282 12:04:46.542 12:04:46.826 12:04:47.027 12:04:47.220 12:04:47.406 12:04:47.727 12:04:48.100 12:04:48.598 12:04:48.858 12:04:49.120 12:04:49.466 12:04:49.639 12:04:49.850 12:04:50.016 12:04:50.218 12:04:50.780 12:04:50.984 12:04:51.151 12:04:51.806 12:04:52.066 12:04:52.326 12:04:52.764 12:04:53.021 12:04:53.576 12:04:53.836 12:04:54.322 12:04:54.634 12:04:54.890 Time FP: User Buffer Size Credits[Bytes/80ms] TransmittedBytes_Bin
Iub Flow Control
based this trace one can clearly see a slow increase of credits even in a single user szenario on a 5xE1 IMA site!
- 113 -
Iub Flow Control
- 114 -
Solutions for Practical Exercises

Part 1: HSDPA Refresher Answer:
- 115 -
- 116 -

Inacon - HSDPA Network Optimization &amp; Troubleshooting

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Inacon - HSDPA Network Optimization &amp; Troubleshooting

Uploaded by

Copyright:

Available Formats

HSDPA Network Optimization & Troubleshooting

HSDPA Network Optimization & Troubleshooting

Color Codes in Frame Formats:

Color Codes in Scenarios:

Signaling Message (mandatory)

Signaling Message (optional)

Foreword of the Publisher:

HSDPA Network Optimization & Troubleshooting

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

HSDPA Network Optimization & Troubleshooting

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

HSDPA Network Optimization & Troubleshooting

Intentionally left blank

HS-SCCH (14) SF 128

HS-PDSCH Symbol Rate

3.84 Mcps / (16 chips/symbol) = 240 Ksymbols/s

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

(2) Example: 16-QAM with R = 2/4 and 10 HS-PDSCHs

QPSK with Code Rate R

QPSK with Code Rate R

16-QAM with Code Rate R

16-QAM with Code Rate R

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

Introduce 2nd UMTS Frequency

Dynamic Code Tree Allocation

PHYSICAL SHARED CHANNEL RECONFIGURATION RESPONSE

SNR (dB) vs. CQI

PHS PDSCH = PCPICH + + . Note that does

Radio Bearer Release:

Radio Bearer Reconfiguration:

Cell Update Confirm Transport Channel Reconfiguration:

Physical Channel Reconfiguration:

Intentionally left blank

Intentionally left blank

Intentionally left blank

Intentionally left blank

Spare bits 7-4

User Buffer Size User Buffer Size (cont) Spare Extension

[3GTS 25.433 (9.2.1.31Ha)]

HS-DSCH Data Transfer procedure

MAC-d PDU Length

Num Of PDUs User Buffer Size

HS-DSCH DATA FRAME

Spare, bits 7-4 MAC-d PDU n

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

MAC-d PDU n (cont)

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

Intentionally left blank

Intentionally left blank

Intentionally left blank

Intentionally left blank

Intentionally left blank

Intentionally left blank

0 107.000 108.000 109.000 110.000 111.000 112.000 113.000

relative Time (s)

Solutions for Practical Exercises

You might also like

Inacon - HSDPA Network Optimization & Troubleshooting

Inacon - HSDPA Network Optimization & Troubleshooting