Академический Документы
Профессиональный Документы
Культура Документы
SAFETY WARNING
Alcatel-Lucent training materials can be for products or refer to products that have both lethal and dangerous voltages
present. Always observe all safety precautions and do not work on the equipment alone. The user is strongly advised not to
wear conductive jewelry while working on the products. Equipment referred to or used during this course may be
electrostatic sensitive. Please observe correct anti-static precautions.
DISCLAIMER
ALCATEL-LUCENT DISCLAIMS ALL WARRANTIES REGARDING THE TRAINING COURSES OR THE CONTENT, EXPRESS OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. THE ALCATEL-LUCENT WILL NOT BE RESPONSIBLE OR LIABLE FOR ANY INJURY, LOSS, CLAIM,
DAMAGE, OR ANY SPECIAL, EXEMPLARY, PUNITIVE, INDIRECT, INCIDENTAL OR CONSEQUENTIAL DAMAGES OF ANY KIND
(INCLUDING WITHOUT LIMITATION LOSS PROFITS OR LOSS SAVINGS), WHETHER BASED IN CONTRACT, TORT, STRICT
LIABILITY OR OTHERWISE, THAT ARISES OUT OF OR IS IN ANY WAY CONNECTED WITH (A) ANY USE OR MISUSE OF THE
CONTENT OR THE TRAINING COURSES BY YOU, OR (B) ANY FAILURE OR DELAY BY ALCATEL-LUCENT, ITS OFFICERS,
DIRECTORS, AGENTS OR EMPLOYEES IN CONNECTION WITH THE CONTENT OR THE TRAINING COURSES (INCLUDING,
WITHOUT LIMITATION, THE USE OF OR INABILITY TO USE ANY COMPONENT OF THE CONTENT OR TRAINING BY
YOU). SOME JURISDICTIONS LIMIT OR PROHIBIT SUCH EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITIES
AND SO THE FOREGOING EXCLUSION OF WARRANTIES OR LIMITATION OF LIABILITY MAY NOT APPLY TO YOU.
GOVERNING LAW
These Terms of Use and Legal Notice are governed by the laws of France. The operation and use of the training course is
governed by the laws of the country that governs your employment contract, if applicable. If any provision of these Terms of
Use and Legal Notice, or the application thereto to a person or circumstance, is held invalid or unenforceable by law, statute
or a court of competent jurisdiction, for any reason, then such provision shall be modified and/or superseded by a provision
that reflects the intent of the original provision as closely as possible. All other provisions of these Terms of Use and Legal
Notice shall remain in full force and effect. You may not assign these Terms of Use or any permission granted hereunder
without Alcatel-Lucent’s prior written consent. Nothing herein shall be deemed an employment agreement or an offer of
employment or an alteration in any way of a user’s terms of employment with or within Alcatel-Lucent.
Copyright © 2011 Alcatel-Lucent. All Rights Reserved
l describe HSDPA activation principles, HSDPA resource allocation parameters, and HSDPA mobility
features
training.feedback@alcatel-lucent.com
Thank you!
Document History
1 HSDPA principles 7
1.1 HSDPA distributed architecture 8
1.2 HSDPA evolution (HSDPA+) 9
1.3 HSDPA UE categories 10
1.4 UE categories and CQI 12
1.5 HSDPA activation flags 13
1.6 Multi-Mode BBU resource allocation 14
1.7 HSDPA/E-DCH service indicator broadcast 15
1.8 Dual cell / dual carrier 16
1.8.1 Simultaneous DC-HSDPA users 17
1.8.2 DC-HSDPA is applicable to multi-RAB 18
1.8.3 DC-HSDPA considerations 19
1.8.4 HSDPA dual cell activation 20
1.9 Transport channel 21
1.10 Physical channels 22
1.11 DL OVSF code tree 23
1.12 (E)-FDPCH 24
1.12.1 User multiplexing with E-FDPCH 25
1.12.2 SRB over HSPA with (E)F-DPCH 26
1.12.3 Criteria for SRB mapping on HSPA 27
1.12.4 Criteria for SRB mapping on HSPA 28
1.12.5 Radio configuration for SRB on HSPA 29
1.12.6 SRB on HSPA in mobility 31
1.12.7 RAN model 33
1.13 HSDPA key features 40
1.14 NodeB scheduler 41
1.15 AMC principles 42
1.15.1 QPSK & 16QAM modulation schemes 43
1.15.2 64 QAM On HSDPA 44
1.16 HARQ types 45
1.16.1 Two H-ARQ combining techniques 46
1.16.2 H-ARQ combining performances 47
1.16.3 Constellation re-arrangement (16QAM only) 48
1.16.4 Redundancy version parameters 49
1.16.5 HARQ stop and wait principles 50
1.16.6 Number of harq processes per UE category 51
1.16.7 HARQ mechanisms 52
1.17 Multi-RAB handling on HSDPA 53
1.18 User services supported with HSDPA – Stand-alone 54
1.19 User services supported with HSDPA - Combination 55
2 HSDPA scheduler 56
2.1 QoS mapping 57
2.2 Scheduling Priority Indicator (SPI) 58
2.3 UE, QId and SPI 59
2.4 Scheduling priority of GBR & retransmissions 60
2.5 User throughput & UE category management 61
2.6 Scheduler xCEM or eCEM 62
2.6.1 SNR ESTIMATION FOR HS-PDSCH 63
2.6.2 TFRC SELECTION 64
2.6.3 TFRC SELECTION summary 65
2.6.4 QoS management for proportional throughput scheduler 66
2.6.5 QoS management for Crmax scheduler 67
3 CQI & MAC-HS BLER management 68
3.1 CQI modification principles 69
3.2 HS-DPCCH detection based on CQI 70
Note that isHsdpaAllowed exists also in two other objects (RNC/NeighboringRNC and
RNC/NodeB/FDDCell/UMTSFddNeighboringCell) in order to know if the HSDPA call has to be reconfigured or not
in DCH when the primary cell changes in case of mobility over Iur.
This feature corresponds to Dual-Cell HSDPA operation in the 3GPP Rel-8 standard. This means that
simultaneous downlink HS-DSCH transmission from two cells, handled by the same BTS, covering the same
geographical area and with adjacent carriers, is supported to a given UE. The two cells involved in the DC
connection of a given UE are referred to as the Anchor (serving) HS-DSCH cell and the secondary HS-DSCH cell.
The secondary HS-DSCH cell is only used for HS-DSCH transmission to the UE.
In fact this UE will be always listening to one and only one cell. There is no soft HO in HSDPA. When we say
« listen » we mean that the UE is decoding the HS-SCCH channel from the Anchor cell. In some TTI, the shared
channel (HS-PDSCH) can be sent over two cells on two adjacent frequencies (carriers).
The UE, in function of its category, can receive over up to 15 SF16 codes on the Anchor cell and simultnously
over up to another 15 codes on the supplementary cell.
OA&M maximum range shows higher values than 15 (42 for xCEM, 64 for eCEM, 42 for UCU-III) but the Node B
has an internal limit to 15. The effective maximum number is minimum (15, OA&M parameter value).
1 DC-HSDPA user is counted as 2 HSDPA connections, among 128 available. This means the numbers of
simultaneous SC-HSDPA users and DC-HSDPA users satisfy the following condition
(Number of SC-HSDPA users + (2 * number of DC-HSDPA users)) <= 128
Thanks to this new channel, several HSPA users can be multiplexed into one SF256 code leading to an OVSF
code savings in downlink. In code limited regime, this savings can be translated into a cell capacity gain.
Based on the SRB RAB matching algorithm, SRBs are mapped onto UL and DL transport channels:
l DL: SRBs are mapped on HS-DSCH in DL
l UL: SRBs are mapped on E-DCH in UL
Each SF16 freed allows one to have 16 SF256 codes . So, with 40 HSDPA users, we need 40 SF256 codes
without FDPCH. Which means that we need to free 3 SF16 codes.
But if we use the FDPCH feature, then each SF256 can multiplex 10 users. So, we need to free only 1 SF16 for
up to 10 (already available SF256) + 160 (16 new SF 256 freed) = 170 HSDPA users!
F-DPCH is configured on all cells of the active set through appropriate OAM parameter:
l isSrbOverHspaEnabled set to True in objects RadioAccessService, FDDCell, NeighbouringRNC and
RemoteFDDCell.
l For case of NeighbouringRNC and RemoteFDDCell, this attribute is not used for UA08, as there is no F-
DPCH support over Iur.
Radio conditions are good enough:
l For call setup, these are based on Measured Results on RACH IE in the RRC CONNECTION REQUEST
message.
l The value is either RSCP or Ec/No, according to the configuration and is compared to newly introduced
thresholds srbOverHspaRscpThreshold and srbOverHspaEcNoThreshold (hysteresis is also introduced
through parameters srbOverHspaRscpHysteresis and srbOverHspaEcNoHysteresis).
l For other triggers, radio conditions are verified each time measurements are received from the serving cell,
either triggered or periodic event (as for RACH, the value is compared with the respective threshold).
l If the radio conditions are below threshold – hysteresis, the SRB is reconfigured on DCH.
The establishment cause is checked, in case of an RRC connection procedure (it is not used for other triggers)
and SRB will be mapped onto HSPA according to the table in this slide.
All these criteria (last one only applicable to the RRC connection phase) are applied each time there is a change
in the call:
l RRC connection setup
l RAB establishment, release and modification
l Mobility
l Always-On
l Reception of Measurement Reports
isSrbOverHspaEnabledForCs indicates if SRB on HSPA with F-DPCH is allowed for configurations with CS.
At call setup, upon reception of the RRC CONNECTION REQUEST message, the RNC checks the different criteria
and, if all the conditions are fulfilled, the call is fully established on F-DPCH/HSPA.
As the UE category is not known at this stage, the call is established on E-DCH using 10-ms TTI (lowest
category 11 for HSDPA and category 1 for E-DCH is assumed).
After reception of RRC CONNECTION SETUP COMPLETE, the UE category is checked (‘Physical Channel
Capability’ in UE Radio Access Capacity IE) and if the E-DCH category is 2, 4 or 6, the UE will be reconfigured to
2-ms TTI at the next RAB establishment, if possible.
The Scheduling Priority of these priority queues are determined in the following way:
From OAM configuration for SRB#1 (through parameter srbOverHsdpaSpi)
The SPI of SRB#2, SRB#3 and SRB#4 are deduced by the RNC:
SPI(SRB#2) = SPI(SRB#1)-1,SPI(SRB#3) = SPI(SRB#1) - 2 and SPI(SRB#4) = SPI(SRB#1) – 3
Parameter srbOverHsdpaSpi should be set to a high value as it is not desirable having low priority for
the SRB on HS-DSCH to avoid SRB traffic delay and possible call drops.
For the UL, SRB will be configured in non-scheduled mode (with max PDU size defined by parameters
maxMacePduContentsSizeForNonScheduledModeTti2 and
maxMacePduContentsSizeForNonScheduledModeTti10) and will use one E-DCH MAC-d flow.
The MAC-e non scheduled mode was used solely to carry SRBs on E-DCH in order to maximize the E-DCH
performances when using 2SF2+2SF4 in case of UE category 6. Now, it may be used in all new cases
of SRBs mapped onto EDCH, introduced by this feature.
For the physical channels, F-DPCH is used in DL and DPCCH is used in UL (they are necessary to perform
power control).
Regarding the cell resource management that is done internally in the RNC, the SRB contribution on power and
code consumption is taken into account as for any other TRB on HSDPA.
l The new parameters srbOverHsdpaGbr and initialActivityFactorSrb are used to estimate the power and code
needed for this SRB on HSDPA.
l The CAC for HSDPA calls is based on a comparison between the current number of HSDPA users and a
maximum configurable number of HSDPA users.
l The number of HSDPA MAC-d flow is not incremented for this new SRB on HSDPA.
This architectural evolution gives a new importance to the role of the Node B in the UTRAN. It then necessarily
goes together with the introduction of some new functions managed by the Node B, including the following:
l FlowControl: new control frames are exchanged in the user plane between Node B and RNC to manage the
data frames sent by the RNC.
l Scheduler: determines for each TTI which users will be served and how many data bits they will receive.
l Hybrid Automatic Repeat Query: retransmissions management.
l AdaptiveModulation and Coding: new channel coding stages and radio modulations schemes are introduced
to provide data throughput flexibility.
l Feedback demodulation and decoding in UL.
Note : when the UE is in compressed mode or in non HSDPA synchronised state (see chapter HS-DPCCH
detection based on CQI, for more details), then the Node B will not schedule it.
New UE categories have been introduced to support the 64QAM :-13 and 14 (64-QAM only), -17 and 18 (64-
QAM or MIMO). These UE categories are MAC-ehs capable MIMO is not supported in UA08.
3 nk+2, nk+3, nk, nk+1 swapping MSBs with LSBs & LSBs values inversion
After a NACK reception or a DTX indication, the HARQ processes are just waiting for being re-scheduled for a
new retransmission.
l Forx/eCEM cards, category 21 to 24 have 12 processes when configured with dual cell call (6 for each cell)
else these also have 6 processes for single carrier HSDPA calls.
If isMultiRabOnHsdpaAllowed is set to False, then the resulting multi-RAB DlUserService will be mapped on
DCH only.
As a consequence:
l UE with a maximum capability of 32kbps does not support:
n PS Streaming DL:64kbps/128kbps/256kbps+PS I/B (HS-DSCH)
n CSD 64 + PS I/B (HS-DSCH)
l UE with a maximum capability of 64kbps does not support:
n PS Streaming DL:128kbps/256kbps+PS I/B (HS-DSCH)
l UE with a maximum capability of 128kbps does not support:
n PS Streaming DL:256kbps+PS I/B (HS-DSCH)
There is no limitation for UE with a maximum capability of 384kbps.
The DL capability with simultaneous HS-DSCH configuration IE is ignored by the RNC in UA05. Consequently,
there will be a failure if the RNC attempts to establish one of the previously listed combinations for the
corresponding UE. To avoid this situation, it is possible to fallback all (CS+)PS Streaming+PS I/B combinations to
DCH.
This option is not activated by default but there is a flag to activate it:
isPsStreamingOnHSDPAAllowed (radioAccessService)
When set to false, all PS I/B + PS Str combinations will be mapped into DCH.
As a consequence:
l UE with a maximum capability of 32kbps does not support:
When the multi-RAB on HSDPA is activated (isMultiRabOnHsdpaAllowed set to True), it is recommended to ensure that
the related DlUserService are enabled for RAB Matching:
• Speech + HSDPA
• CSD + HSDPA
• PS Streaming (DCH or HSDPA) + HSDPA
• Speech + PS Streaming (DCH or HSDPA) + HSDPA
According to the 3GPP (X[R02]X), the UE has to report a CQI assuming a BLER 1st TX of 10%.
Contrary to iCEM, xCEM or eCEM does not directly use the CQI. The received CQI information is mapped to SNR values (SNR MAP,dB) depending
on UE category. The TFRC selection is then based on a second mapping between this SNR and the Spectral Efficiency (SE). The SE defines
the number of bits per HS-PDSCH code per TTI that can be transmitted for a given symbol SNR and SF = 16 (assuming 10% MAC-(e)hs
BLER) in an AWGN channel.
The eligibility of the users is checked based on the number of HARQ processes already used by the user. Note that the 3GPP standard
supports only one priority queue and one HARQ process for each user to be used within one TTI. In case several HARQ processes are ready
for retransmission then priority is given to the process waiting the longest.
HARQ process can be selected for transmission or retransmission only if no ack/nack are expected.
l CostpropTh = (1/SPIweight(u,q)) * J(u,q) / CR(u,q) for non GBR MAC-d flows and for GBR MAC-d flows when R ≥ serviceMinRate
l CostpropTh = (1/(ServiceBFactor(u,q)*100)) * J(u,q) / CR(u,q) for GBR MAC-d flows when R < serviceMinRate(R = Nbr PDU (ACK) x
PDU size / TTI)
l CostCRmax = SW(u,q) . J(uq,) / CR(u,q) for all MAC-d flow types
where
- SPIweight is given by the OAM parameter hsdpaSpiRelativeWeight
- Scheduling weight SW(u,q) allows to control the scheduling priority for each user u and queue q according to the measured MAC-d
Throughput R. This throughput R is defined as the averaged number of ACKed MAC-d PDUs times the PDU size divided by TTI duration to get
the bit rate. The scheduling weight can be controlled by the OMC parameters serviceMinRate, serviceMaxRate, serviceBFactor and
serviceKFactor.
l Job size J(u,q) represents the average throughput of the priority queue (this throughput is smoothed, using an exponential filtering, by
the OAM parameter hsdpaSchedulerWeightingFactorXcem for xCEM or eCEM). The job size is calculated by the MAChs internally for
each user and queue
l Channel rate CR(u) is the spectral efficiency (SE) times the number of available HSDPA code
Note that the cost functions for PropTh and Crmax are strictly the same when the QoS
is disabled. To disable the QoS :
l with PropTh, all the relative weights hsdpaSpiRelativeWeight have to be set with the same value (the value 100 disables totally the SPI
management algorithm) or all the SPI have to be set with the same value (e.g. 0).
l with Crmax, the Scheduling Weight has to be equal to 1 by setting serviceBFactor to 1
GBR Handling:
In the presence of GBR MAC-d flows, these flows will be served first as long as their GBR is not satisfied
(irrespective of their SPI), even if the throughput of non GBR MAC-d flows (and even with higher SPI) must be
reduced down to 0 kbps.
To determine if a GBR MAC-d flow has reached its GBR or not, MAC-(e)hs continuously monitors the average
throughput of the flow (using an exponential filtering based on
hsdpaGbrTbSizeMonitoringForgettingFactorPerSpi parameter). This averaging is needed since the GBR
has to be shown to hold over long-term (hundreds of ms to seconds) compared to the 2ms TTI.
The serviceMinRate used in this type of scheduler is not the equal to the serviceMinRate parameter value but
is calculated by as Mac-(e)hs GBR – serviceLowRate parameter.
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:
In UA06.0, the maximum power that the RNC can allocate to HSxPA channels is defined by:PmaxHspa =
PMaxCell – maxHspaPowerOffset
l TheRNC sends this available power by setting the « HS-PDSCH, HSSCCH, EAGCH, E-RGCH and E-HICH
Total Power » IE in the PHYSICAL SHARED CHANNEL RECONFIGURATION REQUEST message as Pmaxcell
– maxHspaPowerOffset.
n if maxHspaPowerOffset =0, the Node B can use all the available remaining power for HSDPA
transmission
n if maxHspaPowerOffset >0, the operator has the ability to reserve an amount of power which cannot
be used by HSDPA
At nodeB level, with xCEM or eCEM, a minimum percentage of power for HSDPA can be defined through the
parameter hsdpaMinAmpUsage. A percentage of the cell power can also be taken into account to compute
the remaining power (power not used by non HSDPA channels) through hsdpaAmpUsage. Then, the total
power usable for HSDPA is:
PHSDPA total = min(max(hsdpaAmpUsage.Pmax – PTotNonHsdpaWithMargin; hsdpaMinAmpUsage.Pmax);
PmaxHsdpa)
where:
l PTotNonHsdpaWithMargin is the power used by non HSDPA channels with DCH margin.
l Pmax is the maximum power of the cell.
l PmaxHsdpa is maximum power for HSDPA computed by RNC and sent to NodeB through NBAP message.
A HSDPA user is scheduled only if there is enough power for HS-SCCH therefore if the following condition is
fulfilled: PHS-SCCH < PHSDPA.
If not, the scheduler will try to schedule another user.
The computation of the HS-SCCH power is based on the most recent SNRMAP,dB from CQI SNR mapping
for each user, taking into account that HS-SCCH uses an SF128 :
PHS-SCCH = hsscchSnr + PP-CPICH + Γ – SNRMAP,dB – 10.log10(128/16) + 5dB
Where:
l PP-CPICH is the transmitted power of the P-CPICH (in dBm).
l Γ is the measurement power offset.
Note that :
l the maximum value for HS-SCCH power is P-CPICH power + 2dB
l the minimum value for HS-SCCH power is P-CPICH power - 8dB
and:
l Nconfigured is the number of HS-PDSCH codes configured (internal or external PSCR message)
l SumNue capability is the sum of the UE capability of the numberOfHsScchCodes first users at the top of the ranking list
of the previous TTI.
The SE defines the number of bits per HS-PDSCH code per TTI that can be transmitted at a given radio condition.
Note: for xCEM all available HSDPA power is used and shared between the different users each TTI. So, there is no waste of
power.
The HS-DPCCH BLER should be low enough to ensure correct HS-DSCH transmission. A correct demodulation of
CQI ensures suitable transport block transmission. A correct ACK/NACK demodulation ensures a good H-ARQ
efficiency.
The power allocated to the HS-DPCCH is derived from the power of the associated DPCCH taking into account
three specific power offsets. These power offsets should not be set too high in order not to impact the uplink
coverage and capacity.
Offset values are sent to the UE via RRC signaling. These signaled values correspond to predefined (3GPP
standards) quantized amplitude ratios BetaHS/BetaC.
maximumNumberOfUsers is defined in OMC per RNC and corresponds to max HSDPA users per cell.
N.B.:
The iCEM checks the number of HSDPA users per BBU
maxDlRateTransitionToDchDlTriggerDchAndDch
maxUlRateTransitionToDchDlTriggerDchAndDch
Always-On
maxUlRateTransitionToDchDlTriggerHsdpaAndDch
maxDlRateTransitionToDchUlTriggerDchAndDch
maxUlRateTransitionToDchUlTriggerDchAndDch
maxUlRateTransitionToDchUlTriggerHsdpaAndDch
Inter-system HHO can occur following iMCTA Alarm, CAC or Service triggering.
l The selection between FDD and 2G Access is part of iMCTA algorithm, mostly based on UE capabilities,
priority tables and available neighboring cells
R99 traffic can still be allocated in a load balancing fashion as in previous release independently of the HSPA
resource location.
The operator has the possibility to configure HSPA resource (group of several HSPA cells) and the mapping to
the configured xCEM. Each group can be configured with a weight influencing the HSPA resource re-
configuration in case of missing board. The resource assignment algorithm can then take the expected traffic
load of a given cell (configured weight) into account and avoid as much as possible the combination of 2 cells
with heavy load on the same board.
In case of multiple xCEM per carrier, iCEM mixture is not supported. Moreover, in case of iCCM, a maximum of 3
xCEM per Node B can be supported.
The feature allows to guaranty that sufficient baseband processing capacity can be used to target very high
HSDPA data rate (e.g. with 64QAM) in highly loaded sites with high probability of concurrent traffic in all sectors.
It also allows higher HSDPA capacity for sites with more than 3 sectors.
C2 cost takes into account the priority of the QID and mainly depends on the base credits assigned to this SPI
priority and the average CQI.
This is used by both Alcatel-Lucent PF and Classical PF schedulers
The resulting cost is a function of these two costs, and is different according to the scheduler type. Indeed, for
Alcatel-Lucent Proportional Fair scheduler, the resulting cost should be equal to αC1+βC2, while for the Classical
Proportional Fair, the resulting cost is rather equal to γ*C1*C2 (α, β, γ being hard coded). The QId with the
smallest cost is scheduled first. Costs are updated after the QId has been served.
CQI selected depends on CQI reported by UE, the BLER and also the available resources (power, codes, MAC-hs
buffer occupancy & MAC-d PDU size).
Note: The scheduler uses CQI reported by UE for scheduling and uses CQI selected for TFRC selection.
cqiThdHigh, medium and low are hardcoded in the CEM cards as shown:
cqiThdHigh
hdHigh
cqiThdLow
The the HS-DSCH power is equally distributed over all HS-PDSCH codes used to send the Mac-(e)hs block to the
UE.
Note : for xCEM, all available HSDPA power is used and shared between the different users. So, we do not need
this feature, which is valid for iCEM, as iCEM uses power for HSDPA according to a dedicated formula.
Note : for xCEM, all available HSDPA power is used and shared between the different users at each TTI. So,
there is no waste of power and consequently, we do not need this feature, which is valid for iCEM, as iCEM uses
power for HSDPA according to a dedicated formula, in which after scheduling all UE, we can have some unused
power.
This feature is used by iCEM only. xCEM already implements the TBS optimisation (less padding) thanks to
Flexible RLC feature.
Document History
1 HSUPA principles 7
1.1 HSUPA main characteristics 8
1.2 HSUPA activation flags 9
1.3 E-DCH capable UE supported 10
1.4 Multi-Mode BBU resource allocation 11
1.5 E-DCH/HSDPA service indicator broadcast 12
1.6 Scheduling 13
1.7 Physical channels 14
1.8 Multiple E-AGCH and E-RGCH 15
1.9 Physical channels role 16
1.10 Transport channel 17
1.11 E-DCH 2 ms TTI activation 18
1.12 HARQ 19
1.12.1 Compare 10ms TTI and 2 ms TTI E-DCH HARQ 20
1.13 MAC-e non-scheduled mode 21
1.14 User services supported with HSUPA 22
2 HSUPA scheduler 23
2.1 Grant allocation 24
2.2 Priority info support 25
2.3 Scheduler x/eCEM: principle 26
2.3.1 x/eCEM MAC-e scheduler 27
2.3.2 Scheduling weight (SW) 28
2.3.3 Degrant mechanism 29
3 HSUPA radio load & interference management 31
3.1 UL radio load monitoring: needed for E-DCH scheduling 32
3.2 UL radio load monitoring: defense mechanism 33
4 HSUPA power management 35
4.1 DL power management: RNC level 36
4.2 DL power management: NodeB level 37
4.2.1 E-DCH signaling channels power control parameters 38
4.3 UL power management 39
4.3.1 Closed loop power control 40
4.3.2 Scheduling and power offset 41
4.3.3 UL outer loop power control on UL DPDCH (UA05.0) 42
4.3.4 UL OL power control on HARQ retransmission (UA05.1) 43
4.3.4.1 SIR target update decision 44
4.3.5 E-DCH adaptive HARQ control 45
4.3.6 E-DCH adaptive HARQ control – UA08 46
4.3.6.1 Enhanced user activity detection 47
4.3.6.2 Optimized edch harq retrans at cell edge 50
4.3.7 Specific case of SRB on E-DCH 54
4.3.8 Fast decrease of E-DCH partial SIR target 55
4.3.9 Fast decrease of E-DCH partial SIR target – UA08 56
4.3.10 E-DCH partial SIR target in case of soft HO - Definition 57
4.3.11 E-DCH partial SIR target in case of soft HO - Calculation 58
4.3.11.1 E-DCH partial SIR target in case of Soft HO - Exercise 59
4.4 Radio link control - DL/UL imbalance detection 60
5 HSUPA CAC & call management 61
5.1 HSUPA CAC 62
5.2 E-DCH NodeB CAC in UA08 63
5.3 Improved Cac for 2ms Tti users 66
5.4 RAB allocation phase 71
5.5 HSUPA to DCH fallback 72
5.6 Always on: degraded2AOnOnly - URA/cell_PCH used 73
5.6.1 degraded2AOnOnly - URA/cell_PCH not used 74
Fast HARQ
Similar to HSDPA, HSUPA also introduces fast HARQ, which allows the NodeB to rapidly request retransmission
of erroneously received data. HARQ reduces the number of retransmissions at the RLC layer and shortens the
transmission delay. The NodeB performs soft combining of data erroneously received and data retransmitted
from the UE before decoding. The combining uses the information transmitted each time and thus increases the
success rate of decoding.
Shorter TTI
HSUPA allows a 2 ms TTI, which further reduces the transmission delay and scheduling delay.
Macro Diversity
HSUPA supports soft handover. The cells in the active set can receive data from UEs. Macro diversity increases
the probability of proper data reception, improves the quality of data transmission, and greatly enhances the
service stability of users at the cell border.
Note that since UA07, it is recommended to set maxNrOfErgchEhich to 1 in order to save DL codes and to favor
HSDPA+ performances.
The MAC-e scheduler runs every 40ms for UEs configured with 2ms TTI or 10ms TTI.
l PS Streaming + E-DCH
l This feature aims at providing support of PS I/B+PS I/B and related combinations with CS on HSUPA
l RAB combinations shall be then supported for 2ms and for 10ms TTI as well.
Note: isMultiRabOnEdchAllowed can be set to TRUE only if isMultiRabOnHsdpaAllowed is set to TRUE.
l UE status: UE category, SI
l NodeB resources
l E-DCH processing resources are pooled across cells handled by one x/eCEM.
l The Maximum Target Received Total Wide Band Power sent over NBAP in PHYSICAL SHARED
CHANNEL RECONFIGURATION REQUEST message. It is derived from OMC-R parameters
FddCell→TotalRotMax and FddCEll→RtwpRef. RTWPref will be adjusted according to self-learned
RTWP value in the NodeB, as well as the resulting RoT.
l The target UL load Ltarget is derived and is defined as the most restricting criterion among above limitations
l Measurements
l x/eCEM estimates every 10ms the average total UL load LE-DCH generated by E-DCH serving users.
l The available E-DCH load is derived and corresponds to Lavailable, E-DCH = Ltarget - Lnon E-DCH. If Lavailable, E-
DCH <= 0, then the cell is overloaded.
l UE specific information
l Scheduling information
Where the term w depends on whether the measured MAC-d throughput R is lower or higher than
serviceMinRate:
The MAC-e scheduler de-grants the UE with lowest priority and updates the hypothetical load and repeats the
procedure as long as Lhypothetical > Lavailable. Each UE will be de-granted by 1 step at the maximum.
l When average throughput for MAC-d flow#i is lower than serviceMinRate (configured per Scheduling
Priory Level) the MAC-e scheduler shall increase the rank until the average throughput is equal to the
serviceMinRate. The resources are taken from the MAC-d flows that have an average throughput higher
than their serviceMinRate and especially those with an average throughput higher than their
serviceMaxRate. In overload situation, UEs in bad RF conditions will remain with throughput lower than
serviceMinRate. However, this behavior can be overruled by adjusting the serviceBFactor and
serviceKFactor to allow UE with bad RF conditions to achieve serviceMinRate.
l When average throughput for MAC-d flow#i is higher than serviceMaxRate (configured per Scheduling
Priory Level) the MAC-e scheduler shall decrease the rank until resources are given to those with average
throughput lower than serviceMinRate.
When the average throughput is between serviceMinRate and serviceMaxRate, a given {UE, MAC-d flow}
will be ranked higher if RF conditions are better. {UE, MAC-d flow} with same RF conditions, but different SPI,
will be ranked considering edchSpiRelativeWeight.
B = 7, K = 7 B = 5, K = 7 B = 3, K = 7 B = 1, K = 7
5
Priority
0
20 30 40 50 60 70 80
Data Rate [kbps]
B = 7, K = 7 B = 7, K = 5 B = 7, K = 3 B = 7, K = 1
5
Priority
0
20 30 40 50 60 70 80
Data Rate [kbps]
The xCEM overload algorithm is trigged when the average non E-DCH load, estimated based on the last received
RTWP measurement, is higher than the “E-DCH Max load” corresponding to RoT_max setting.
This RoT is creating UL interferences. In an HSUPA-capable cell suffering from strong interference, the cell
throughput is extremely low, resulting in an adverse HSUPA-user experience.
This can create also issues on BTS reception for non closed loope power controlled messages. Especially the RRC
connection Request. This might create UL coverture issues and bad MTC Call Setup Success Rate.
In UA05.0, the Open Loop PC is based on the UL quality of the associated UL DCH channel, means on the UL
SRB data transmission.
l On event,
i.e. if 1 Partial SIR Tg increased more than updateThreshold since previous update.
For the UL services with E-DCH, the E-DCH transport channel must be set as a reference channel for the driving
of UL OLPC. This can be done by making sure that an instance of ReferenceUlRbSetList with
referenceUlRbSetConfId set to “UlRbSetConf/PS_EDCH” exists for all UL services with E-DCH. If such
instance of ReferenceUlRbSetList does not exist, it must be created.
Note: The E-DCH TTI2ms calls require high SIR Target values to reach the best performances. A special set of
parameters is defined, allowing SIR target differentiation between E-DCH TTI10ms and 2ms.
eligibleUeCategoryForSirTargetEdch2ms: Eligible UE E-DCH categories for specific SIR target settings (in
case of E-DCH TTI 2ms). The bit 0 corresponds to category 1, bit 1 corresponds to category 2 and so on. The
recommended setting allows having E-DCH UeCategory2, UeCategory4 and UeCategory6 eligible for specific SIR
settings when they are using TTI2ms.
For the UE for which eligibleUeCategoryForSirTargetEdch2ms is set to True, then the SIR target
parameters to be used when 2ms TTI is used are:
l initialSirTargetEdch2ms instead of initialSirTarget or initialSirTargetHsdpa
iCEM : Adaptive HARQ control is not used, because lab tests shown that there is no gain, and we can even have
degradation. So, we use value corresponding to S1 state.
The throughput Rj,i of each MAC-d flow i for each eligible user j (serving E-DCH user in CELL_DCH) shall be
measured over a certain measurement window averageWindow.
Lj: set containing the MAC-d flows of user j carrying streaming or interactive/background traffic over E-DCH.
Uplane will actually count the number of windows for which the user is inactive as follows:
floor (timeToTriggerForInactiveState/ averageWindow) = floor (1000/300) = 3 => 3 windows of 300ms.
An E-DCH user j is reported as "active" when its measured throughput Rj by U-Plane rises above OAM parameter
thrThresholdForActiveState and the user was in "inactive" state before.
Last Actual Num HARQ ReTx Target is the actual number of target HARQ transmissions according to the
standard OLPC mechanism.
It will be possible in UA08 to make E-DCH OLPC more efficient in order to help enhance cell capacity with
minimal impact on user throughput. UE power is reduced by a significant amount upon traffic inactivity in order
to quickly reduce interference to other users residing in the same cell.
User inactivity is defined as non received MAC-d PDUs for a call, on all the existing MAC-d flows, including E-DCH,
SRB and DCH RABs.
The activation parameter of the fast decrease of the E-DCH partial SIR target in UA08 is
isEdchFastSirTargetDecreaseAllowed.
Traffic inactivity must persist for a configurable period of time before applying the fast decreased power. This
can be configured using the parameter eDCHOlpcInactivityTimeThreshold.
The decrease of the UL SIR target due to inactivity is set to an optimum value so that it does not adversely
impact the performance of UL physical control channels. This can be configured using the parameter
eDCHOlpcInactivitySIRDecreaseLimit.
Finally, the preserved UL SIR target values of all existing MAC-d flows shall be restored following detection of
activity, i.e. receipt of MAC-d PDUs at RNC on any MAC-d flow. Initial power (saved right before fast decrease
process) is reinstated as soon as traffic resumes, on any of the RABs.
When the UE is in E-DCH SHO, the analysis at RNC of HARQ Failure Indication (HFI) messages received from the
E-DCH serving NodeB and the E-DCH Data Frames correctly received from the serving and non-serving NodeB(s)
allows adapting the Partial SIR Target(s) of E-DCH MAC-d flow(s) according to the type of E-DCH SHO scenario
detected.
At the RNC, the HFI messages received from the E-DCH serving NodeB and the E-DCH Data Frames correctly
received from the serving and non-serving NodeB(s) are processed to determine an E-DCH SHO scenario (HFI
Reception Scenario).
This E-DCH enhanced Node B CAC improves the control of E-DCH performance, by giving some means to the
operator to limit the maximum number of E-DCH 2-ms TTI connections handled per xCEM or eCEM.
This feature thus allows one to benefit from the 2-ms TTI advantages, while maintaining the possibility to still
set up up to 128 E-DCH connections, despite the limit of 32 2 ms. The threshold operates as the trade-off point
between capacity and performance. In case of high load (number of used credits above the threshold), only 10
ms is accepted. When a call previously set up using a 2-ms TTI is released or transferred to CELL_FACH state, it
frees 4 credits. If the overall load remains above the threshold, a new call will be set up using a 10-ms TTI,
consuming a single credit. Thus, progressively, 2-ms TTI calls are exchanged with 10-ms TTI calls. Conversely,
when the load decreases (goes below the threshold), 10-ms TTI calls can be progressively exchanged for 2-ms
TTI calls.
For eCEM, the same principle applies with however one major difference: the eCEM can handle as many 2 ms
TTI users as 10 ms TTI users from HW point of view.
eCEM
l If HsupaCellParams::EdchMaxThroughput = MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCACECem
l Else, if HsupaCellParams::EdchMaxThroughput ≠ MAXINT (0xFFFFFFFF):
Requested_decoding_rate_limit =
relativeRequestedDecodingRateLimitForCAC*HsupaCellParams::EdchMaxThroughput
UCU-III
The total requested decoding rate limit per UCU board shall be directly configured as:
Requested_decoding_rate_limit = absoluteRequestedDecodingRateLimitForCAC
The actual total requested decoding rate shall be determined per baseband board at each EDCH scheduling
interval as follows:
Total_Requested_decoding_rate = TBsum / EDCH_scheduling_interval
Where:
n TBsum comprises all transport block sizes TBi and TBj for all serving users ui and all non-serving
users uj served by one baseband board that are received within the time EDCH_scheduling_interval
regardless whether a valid E-DPDCH scheduler data packet was received or not.
n EDCH_scheduling_interval is the time between two runs of the E-DCH scheduler. It is hard-coded to
40 ms.
If Block_2msTTI_users = TRUE:
l Onreception of NBAP Radio Link Reconfiguration Prepare message for 2-ms TTI, the Node B shall respond
with an NBAP Radio Link Reconfiguration Failure message with cause “Not enough User Plane Processing
Resources”
l Onreception of NBAP Radio Link Setup/Addition request message for 2-ms TTI, the Node B shall respond
with an NBAP Radio Link Setup/Addition Failure message with cause “Not enough User Plane Processing
Resources”
Note: In case of multiple xCEM/eCEM/UCU-III boards, if possible, non serving RLs should be set up on a
board for which Block_2msTTI_users flag is FALSE.
In case a 2-ms TTI E-DCH call cannot be admitted, the call shall be handled as follows:
l For the E-DCH serving RLS, the call shall be set up as a 10-ms TTI E-DCH call.
l Fora non-serving radio link, the failed radio link is added to the DCH active set but not added to the E-DCH
active set.
In case the DRNC receives an NBAP Radio Link Setup/Addition Failure message with cause value "Not enough
User Plane Processing Resources", it shall send the RNSAP Radio Link Setup/Addition Failure message with
cause value "E-DCH TTI2ms not supported" to the SRNC.
The failed radio link is added to the DCH active set but not added to E-DCH active set. The DRNC informs the
SRNC by setting the corresponding E-DCH IE to FALSE in the response message.
For a given E-DCH call, E-DCH Configuration is common to all E-DCH RLs.
l E-DCH Configuration is determined by RNC at beginning of the E-DCH call,
basing on UE and E-DCH serving NodeB capabilities.
l E-DCH Configuration must always match E-DCH serving cell (i.e. Primary Cell) capabilities
At Primary Cell change, E-DCH Configuration is changed to match E-DCH capabilities of
the new Primary Cell (if E-DCH capabilities changed).
iCEM/x/eCEM specificities:
iCEM and x/eCEM capabilities are different regarding E-DCH TTI and E-DPDCH SF
E-DCH call attributes depend on type of board handling E-DCH on the E-DCH serving cell.
Example:
UE: HSUPA Category 5, “IR” E-DCH HARQ type supported:
l iCEM handling E-DCH on E-DCH serving cell {10ms TTI, 2xSF4, IR}, “Cat 3” Ref E-TFCI table
l x/eCEM handling E-DCH on E-DCH serving cell {10ms TTI, 2xSF2, IR}, “Cat 5” Ref E-TFCI table
Note that the parameters rtwpMargin and rtwpTimeDetection are not used for xCEM overload algorithm.
The xCEM overload algorithm is trigged when the average non E-DCH load, estimated based on the last received
RTWP measurement, is higher than the “E-DCH Max load” corresponding to RoT_max setting.
When channel profile has poor orthogonality, MAC-e scheduler should allocate lower grant than when
orthogonality is good.
Document History
l MT CS Conversational Call: Mobile terminated CS voice or data call over DCH (UEs <Rel-6)
l CS Voice Call: Mobile originated or terminated CS voice call on DCH, if the use of RRC establishment cause
is disabled (UEs > = Rel-6)
l CS Data Call: Mobile originated or terminated CS data call on DCH, if the use of RRC establishment cause is
disabled (UEs > = Rel-6)
l PS DCH Call: PS data call over DCH
l DC Data Call: PS data call over HSPA and dual cell option
l LTE Data Call: PS data call over HSPA and LTE redirection option
l Other Call: Signaling connections (e.g. location registrations). If the operator has disabled the use of the
RRC establishment cause by setting isRedirectionBasedOnEstablishmentCause to FALSE , then “Other
Call” includes all calls for UEs < Rel-5 and all calls for Rel-5 UEs in CS domain (for all Rel-5 UEs in the PS
domain “HSDPA Data Call” is assumed).
Carrier Selection
Algorithm
N
Call Type
in Action List?
Carrier
Selection List
Processing
N
Output: Target Carrier
End of Y Target Carrier (FDD cell or RAT)
Action List? empty?
Y N
Update redirection
percentage figure
N Redirection
required according
to percentage
Target carrier = figure? Target carrier =
originating cell originating cell
Y
End
The load criterion to be used for load comparison depends on the call type, the UE´s HSDPA/HSUPA capability
and the FDD cell capability. The following load criteria are fixed coded:
The 2nd and 3rd criteria are only applied, if the previous selection criterion results in multiple cells with the same
load. The calculated DCH cell load value is derived from the individual cell loads and their weighted load color.
Document History
121 E-TFCI are defined for table 1 (128 for table 0).
In order not to signal all power offsets, only few of them are signaled as reference. Each reference element
contains a couple of values :
l Reference E-TFCI (Transport block size index, range [0-127])
l Reference Power Offset (E-DPDCH/UL DPCCH power ratio index, range [0-29])
Non referenced Power Offsets are obtained by interpolation at the UE , according to the interpolation method
specified by 3GPP in TS 25.214 .
l Maximal MAC-hs payload size given by the UE capability and the queue size
The spectral efficiency is a metric how many bits/code/TTI can be transmitted successfully in a TTI
l The CQI is not directly used in the MAC-hs but mapped to a SNR per code based on PCPICH +
measurement power offset
l Based on the available HSDPA power the SNR is scaled and mapped to a spectral efficiency (SE) in
bits/code/TTI
Since the spectral efficiency is based on the truly available HSDPA power, the TFRC selection is not limited by
PCPICH + measurement power offset
The LUT is defined so that chosen modulation efficiently uses resources (power and codes)
l In power limited situation QPSK is preferable (lower Es/N0)
è more codes but increases the transport block size for the same power
l In code limited situation 16-QAM is preferable (higher Es/N0) :
è more power but increases the transport block size for the same number of codes
Document History
T
TAF That's All Folks!
TB Transport Block
TBS Transport Block Size
TC Traffic Class
TCP Transmission Control Protocol
TDD Time Division Duplex
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
TF Transport Format
TFC Transport Format Combination
TFCI Transport Format Combination
Indicator
TFI Transport Format Indicator
TFO Tandem Free Operation
TFRC Transport Format and Resource
Combination
TFRI Transport Format and Resource
Indicator
TFS Transport Format Set
THP Traffic Handling Priority
TPC Transmit Power Control