HSDPA mobility


The HSDPA mobility handling takes care of the data connection mobility when the 
HSDPA is active for the connection. This functionality can be enhanced by optional 
enhanced functionality.

HSDPA Basic functionality
If the parameter HSDPAmobility has value disabled, the HSDPA mobility is handled 
by HSDPA cell reselection and DCH switching. 
HSDPA cell reselection is triggered by measurement event 1A, when the UE enters the 
SHO area. The reselection applies transitions to CELL_FACH, cell re-selection and reallocation of HSDPA. The measurement event 1A can be configured with the 
AdditionWindow parameter, defined in the FMCS parameter set that is selected by 
HSDPAFMCSidentifier or RTwithHSDPAFMCSidentifier parameters.
Switching to DCH is triggered by measurement events 1F and 6A. They also trigger 
directly the IFHO/ISHO measurements when HSDPA+AMR multi-RAB is used. Direct 
switching from HSDPA to DCH initial bit rate is used when possible.



Optional enhanced functionality
The optional enhanced functionality enables the usage of HSDPA Serving Cell Change 
and HSDPA Soft/Softer Handover for Associated DPCH. This feature is activated by 
setting the parameter HSDPAmobility to value Enabled. An active license is required 
for this feature. 
The HS-DSCH serving cell change feature is controlled with several planning parameters. There are feature-specific parameters to set thresholds for the Ec/No and UL SIR 
error triggering and the required level in a target cell. In addition to the feature-specific 
parameters, AdditionWindow and DropWindow parameters in the HSDPA FMCS 
parameter set are used to control the serving cell change and the SHO area for the 
associated UL channels. 
The HS-DSCH serving cell change feature can be triggered by the best server Ec/No, 
UL SIR error, and event 1B/1C. The most common triggering reason is the periodical 
Ec/No measurements. The HSDPAServCellWindow parameter determines the 
maximum allowed difference between the best cell Common Pilot Channel (CPICH) 
Ec/No and the serving HS-DSCH cell CPICH Ec/No. It is recommended to set the 
DropWindow parameter higher than the HSDPAServCellWindow, so that the serving 
cell change is normally triggered by the Ec/No measurements and not by the event 1B. 
The AdditionWindow in the HSDPA Intra-Frequency Measurement Control (FMCS) 
controls the active set size of the associated UL channels. It does not have direct impact 
on the serving cell change functionality and triggering. However, the used High-Speed 
Dedicated Physical Control Channel (HS-DPCCH) power offsets for the Channel Quality 
Indicator (CQI) and HARQ Ack/Nack are higher during the SHO of the associated channels. It is recommended currently to set a lower value for the AdditionWindow parameter in HSDPA FMCS than in the RT/NRT FMCS, to have a smaller SHO area for the 
HSDPA users. 
Switching to DCH is triggered by measurement events 1F and 6A also with enhanced 
functionality. They also trigger directly the IFHO/ISHO measurements when

HSDPA+AMR multi-RAB is used. Direct switching from HSDPA to DCH initial bit rate is 
used when possible. 
The measurement control and handover path parameter sets, which are dedicated to 
the UE having HS-DSCH transport channel allocated, are applied to the intra-, inter-frequency, and inter-RAT measurement types. The separate, HSDPA-specific and RT with 
HSDPA multi-RAB, measurement control and handover path parameter sets are determined for the following parameter object classes:
 • FMCS (intra-frequency measurement control)
 • FMCI (inter-frequency measurement control)
 • FMCG (inter-system measurement control)
 • HOPS (intra-frequency handover path)
A particular parameter set is associated with the HSDPA UE by the following identifiers: 
HsdpaFmcsIdentifier, HsdpaFmciIdentifier, HsdpaFmcgIdentifier, 
HsdpaHopsIdentifier. 
The Radio Network Planning (RNP) parameters can be adjusted by the operator.

Key HSPA features and parameters

All High-Speed Packet Access (HSPA) -related features and parameters are 

described in detail in WCDMA RAN Parameter Dictionary.

The most important features and parameters from network planning point of view are 

presented here. For detailed information about features, see HSDPA-related feature 

documentation.

Table 5 HSDPA resource management functionality

HSDPA Basic functionality
In HSDPA Basic functionality, the features consist of QPSK and 5 HS-PDSCH codes, 
basic characteristics of the feature are listed below:
 • Maximum number of HSDPA users per BTS is 16
 • Maximum HS-SCCH codes per cell is 1
 • Maximum HS-PDSCH codes per cell is 5
 • Up to 3 cells per BTS can be enabled for HSDPA
In HSDPA Basic functionality the maximum allowed HSDPA power can be limited with 
PtxMaxHSDPA parameter. The recommended value for PtxmaxHSDPA depends on the 
HSDPA implementation strategy, HSDPA throughput targets, and Dedicated Traffic 
Channel (DCH) traffic load. For a shared HSDPA+DCH carrier the recommended 
HSDPA power is 4 - 7 W. For a dedicated HSDPA carrier the HSDPA power can be 10 
- 12 W when the maximum power of the Base Transceiver Station (BTS) is 20 W. 
Nokia Siemens Networks BTS utilises dynamic power allocation for HSDPA power, 
meaning that all available power is allocated to HSDPA when it is active until the 
maximum limited by PtxMaxHSDPA parameter.





The maximum HSDPA power should be selected so that the interference due to the 
HSDPA power does not cause severe degradation to the Real Time (RT) DCH and Nonreal Time (NRT) performance. The dynamic HSDPA power control makes the use of 
higher HSDPA power possible when the DCH traffic load is low. If the DCH load 
increases, the HSDPA power reduces dynamically. 
Figure HSDPA power allocation and load control thresholds with HSDPAPriority=1
shows the load and power control actions in case of HSDPAPriority=1. The 
PtxMaxHSDPA parameter defines the maximum power the BTS can allocate for the 
HSDPA. The HSDPA power is reduced when the required power for non-HSDPA connections increases and the total transmission power of the BTS reaches the maximum 
allowed Txpower. Preventive load control actions are started when the non-HSDPA 
power exceeds the PtxTargetHSDPA threshold. Overload control actions are started 
when the non-HSDPA power exceeds the PtxTargetHSDPA+PtxOffsetHSDPA
threshold. In case of HSDPAPriority=1, the overload actions are first targeted to the 
DCH NRT data bearers.

BTS maximum TX power is the cell maximum output power defined as minimum of the 
management parameter PtxCellMax and the BTS capability (indicated by 
MaxDLPowerCapability). 
In case of HSDPAPriority=2, the overload actions are first targeted to HSDPA power, 
as Figure HSDPA power allocation and load control thresholds with HSDPAPriority=2
shows.

Figure 12 HSDPA power allocation and load control thresholds with HSDPAPriority=2

A fixed number of five HS-PDSCH codes is reserved for HSDPA when it is enabled in 

cell.

Optional enhanced functionality

RNC applies HSDPA dynamic resource allocation if parameter 

HSDPADynamicResourceAllocation is set to ‘Enabled’. This enables the usage of 

dynamic NRT DCH scheduling and dynamic allocation of HS-DSCH codes. 

One option is that the HSDPA power is not limited by PtxMaxHSDPA, but BTS allocates 

all available power until BTS maximum TX power, which is the power defined as 

minimum of the management parameter PtxCellMax and the BTS capability (indicated 

by MaxDLPowerCapability). PtxCellMax can be used to limit the total power of the 

base station which limits also the downlink noise rise and enhances performance at cell 

edge areas. Another option is that PtxMaxHSDPA is used to limit the HSDPA power, 

which then avoids sudden power peaks already from one HSDPA user.

With dynamic NRT DCH scheduling the RNC uses an internal dynamic target 

PtxTargetPS for NRT DCH scheduling instead of fixed target like 

PtxTarget/PtxTargetHSDPA. This dynamic target is adjusted based on relative 

number and priority of HSDPA and NRT DCH users. The priority is defined by network 

planner separately for HSDPA (WeightHSDPA parameter) and NRT DCH (WeightDCH

parameter) users and also based on the bearer traffic class. 

The dynamic target PtxTargetPS is limited by minimum and maximum limits set by the 

network planner with PtxTargetPSMin and PtxTargetPSMax parameters. These 

can be used directly to limit the NRT DCH power and guarantee wanted power to 

HSDPA.

Nokia Siemens Networks RAN Optional feature set includes also HSDPA Dynamic 
Resource Allocation feature which is required to enable the usage of more than 5 HSPDSCH codes in a cell. HSDPA Dynamic Resource Allocation applied if:
 • HSDPA Dynamic Resource Allocation is activated/enabled 
(HSDPADynamicResourceAllocation management parameter)
 • Either HSDPA 10 Codes (HSDPA10Codes) or HSDPA 15 Codes (HSDPA15Codes) 
is activated/enabled
BTS must also be capable of 10/15 codes to dynamically adjust HS-PDSCH codes.
Maximum bit rate of HS-DSCH MAC-d flow
The maximum user bit rate of the HS-DSCH MAC-d flow used in the resource reservation for the HS-DSCH MAC-d flow is limited by the maximum bit rate based on User 
Equipment (UE) capability, the value of management parameter 
MaxBitRateNRTMACDFlow and by the maximum bit rate in RAB QoS parameters. 
The value of MaxBitRateNRTMACDFlow does not limit the maximum instantaneous bit 
rate on the air interface. The value of the parameter is compared to the user bit rate of 
the HS-DSCH MAC-d flow, excluding MAC-hs header, RLC header and padding. 
The maximum bit rate in RAB QoS parameters is checked only if management parameter HSDPAPeakRateLimitRABMax is set to value 1 (limitation is active). 
In RU10, one user L1 throughput can go up to 14.4 Mbps, which is possible with HSDPA 
UE category 10. Thus, it means that maximum bit rate of HS-DSCH MAC-d flow is 
around 14 Mbps. Notice that this is achieved with coding rate 1 which means that it 
requires error free transition and reception.

HSDPA quality of service (QoS) management

HSDPA QoS management functionality allows to prioritize different QoS traffic class RABs on the HS-DSCH. The optional QoS Aware HSPA Scheduling feature is applied if the following conditions are fulfilled:

• HSDPA Dynamic Resource Allocation optional feature is used in the cell (HSDPADynamicResourceAllocation parameter is set to 'Enabled')
• QoS Aware HSPA Scheduling optional feature activated on cell level via the HSPAQoSEnabled RNP parameter

Whenever the optional QoS Aware HSPA Scheduling feature (HSPAQoSEnabled RNP parameter set to 'Enabled') is used, prioritizing RABs of interactive and background QoS traffic classes mapped to HSDPA transport channels is based on the following parameters received from the core network:

• Signaling indication
• Traffic class (TC)
• Traffic handling priority (THP)
• Allocation retention priority (ARP)

The latter three parameters (TC, THP, and ARP) are mapped according to operator-defined rules to the respective prioritization value used in the RNC. The mapping is realized via the QoSPriorityMapping RNP parameter. Whenever the HS-DSCH is affected, the relevant value is then sent to the BTS as scheduling priority indicator (SPI) value.

Additionally, the Streaming QoS for HSPA optional feature defines whether or not streaming RABs may be mapped to the HS-DSCH and handled by HSDPA QoS management. QoS support for PS streaming RBs mapped to the HS-DSCH is only applied if the HSPAQoSEnabled RNP parameter set to value '2' and the prerequisites for QoS Aware HSPA Scheduling are fulfilled.

Note that if the Streaming QoS for HSPA optional feature is not activated within the cell, RABs with streaming QoS traffic class cannot be mapped to the HS-DSCH but can be used on DCH. Furthermore, if the HSDPA Dynamic Resource Allocation optional feature is not activated (via the HSDPADynamicResourceAllocation RNP parameter), RABs with streaming QoS traffic class must not be mapped to the HS-DSCH but have to be used on DCH.

Basic principles and QoS prioritization decision

Based on the before-mentioned RNP parameters' values defined by the operator and the values of the parameters received via RANAP and RNSAP (TC, THP, ARP), QoS prioritization of RABs is handled with the QoSPriorityMapping RNP parameter. Whenever the received THP or ARP values are not smaller than or equal to three (3), value 3 is used for the mapping with the restriction that a maximum of 16 different priorities can be used.

The basic principles applied for QoS-based prioritizing of QoS classes are the following:

• Priorities for DCH streaming, interactive, and background connections are always read from the QoSPriorityMapping parameters
• Priority of non-realtime (NRT) RABs mapped to the HS-DSCH depends on whether or not QoS prioritization for NRT services is activated in the cell:
  • If QoS prioritization for NRT services is activated, the actual priority for these RABs is read from the structured QoSPriorityMapping parameters, defined on RNC level.
  • Otherwise, if QoS prioritization for NRT services is not activated, the actual priority for these RABs is always equal to zero (0).
• Priority of streaming RABs mapped to the HS-DSCH depends on whether or not streaming in HSDPA transport channels is activated in the cell
  • If streaming in HSDPA transport channels is activated, the actual priority for these RABs is read from the QoSPriorityMapping parameters.
  • Otherwise, if streaming in HSDPA transport channels is not activated, the actual priority for these RABs is always equal to zero (0).
• Priority of interactive signaling RABs has to be larger than the priority used for any other NRT service

The following table provides the default values of the QoSPriorityMapping parameters, which allow to define different priorities depending on the QoS class and the RAB's priority type.

QoS Class	Priority Type	Priority Value
Streaming	ARP 1	13
	ARP 2	13
	ARP 3	13
Interactive	Signaling	12
	THP 1 ARP 1	11
	THP 1ARP 2	11
	THP 1 ARP 3	11
	THP 2 ARP 1	8
	THP 2 ARP 2	8
	THP 2 ARP 3	8
	THP 3 ARP 1	5
	THP 3 ARP 2	5
	THP 3 ARP 3	5
Background	ARP 1	0
	ARP 2	0
	ARP 3	0

Table 1:

Default values of the QoSPriorityMapping parameters

Whenever the mapping of QoS priorities has been changed, these changes become effective for only those RABs to which DCH or HS-DSCH allocation or reconfiguration is applied afterward. As regards HS-DSCHs, the assigned priority is then directly used as SPI value which, in turn, is sent to the BTS. An SPI value equal to zero (0) is transmitted whenever the optional QoS Aware HSPA Scheduling feature is deactivated (HSPAQoSEnabled RNP parameter set to “Disabled”). Dedicated channels (DCHs) have a value in the range between zero (0) and 15, indicating the lowest and highest priority values, respectively.

How the various RAB parameters (TC, THP, ARP) received via RANAP or RNSAP are handled during branch addition or relocation, depends on the actual scenario:

• Branch addition over Iur interface
  When a branch is added to the drift RNC (DRNC), the TC, ARP and frame handling priority (FHP) parameters are received via the Iur interface. Admission control then defines the THP, based on the received FHP value, see Definition of the NBAP/RNSAP frame handling priorities in SRNC in WCDMA RAN RRM Admission Control. If the source RNC (SRNC; from a different manufacturer than Nokia Siemens Networks) then sends an FHP value which is higher or lower than the one defined by admission control for PS interactive services,
  • THP is adjusted to the nearest THP value in the mapping table.
  • FHP is not changed and remains as it has been received. The RNC then sends the FHP value to the BTS via NBAP message.
  The RNC uses the mapped THP value as well as the received TC and ARP values to define the QoS priority. This priority is only forwarded to transport network layer when the branch is set up. In this way, the transport priority is as exact as it can be with the information available.
• UE not involved relocation
  In this scenario, the target RNC defines the QoS priority from RAB parameters (TC, ARP, THP) received in RANAP: Relocation Request message. While the cell-specific packet scheduler becomes immediately aware of the defined QoS priority and RAB parameters, either of them will only be updated on the transport layer either
  • When the next channel type switch back to HSPA channel configuration occurs, for example, or
  • After inactivity resources are again needed for data transmission.
• UE involved relocation
  In the event of a hard handover (UE involved relocation), the target RNC defines the QoS priority from RAB parameters (TC, ARP, THP) received in RANAP: Relocation Request message. In this way, both the QoS priority and the RAB parameters are known when radio channels are allocated and set up on the transport network layer.

Nominal bit rates for HSDPA non-realtime (NRT) services

The nominal bit rate (NBR) is defined as the bit rate which is set in the RNC for NRT HS-DSCHs and sent to the BTS as guaranteed bit rate (GBR). The principles of NBR thus are the following:

• NBRs can only be used for NRT traffic classes.
• NBRs are applied in only those cells for which streaming in HSDPA transport channels is activated (HSPAQoSEnabled RNP parameter set to “Enabled”). Otherwise, an NBR value equal to zero (0) will be applied.
• For each QoS priority value used for the respective NRT traffic classes, NBRs can be defined either for both uplink (UL) and downlink (DL) directions or for only one direction.
• Priorities which have been assigned NBRs have to form a continuous block within the QoSPriorityMapping parameter, starting with the highest priority used for NRT services. After this block, traffic classes in the QoSPriorityMapping parameter have to be ordered as follows:

  1.	Priorities used by streaming services Their NBR always equals to zero (0); their priority value, however, is larger than the ones used for NRT users having defined QoS.
  2.	Priorities used by NRT users having defined QoS The NBR of these users is specified for at least one direction (UL or DL or both).
  3.	Priorities used by best effort (BE) users, i.e. NRT users without QoS. Their NBR always equals to zero (0).

In the RNC, NBRs are managed and stored using the structured HSPANBRValues RNP parameter, which is defined on RNC level. The HSPANBRValues parameter allows to specify NBRs for UL and DL directions for those HS-DSCHs with priority values (QoSPriorityMapping parameter) in the range between zero (0) and twelve (12). Whenever the defined NBR values are modified, the changes will become effective only for new RABs, while the mapping for existing RABs remains unchanged.

Whenever a RAB's maximum bit rate is smaller than the NBR defined for this QoS class and priority type, this maximum bit rate will be used as the RAB's NBR value and only the resources required for this bit rate are reserved. Otherwise, resources would be wasted.

Cell-level measurements used by PS streaming

If HSPA streaming is activated in a particular cell by setting the HSPAQoSEnabled parameter appropriately, two measurements are initiated: HS-DSCH provided bit rate measurement (PtxHSProBR) and HS-DSCH required power measurement (PtxHSRePo).

For each scheduling priority indicator (SPI), the WBTS measures both the provided bit rate and the power required by the HS-DSCH and reports the measured values to the RNC via the Nokia-proprietary NBAP: Radio Resource Measurement Report message. For the purpose of higher-layer filtering, the RNC informs the WBTS about the filter coefficient to be used, using the Nokia-proprietary NBAP:Radio Resource Measurement Initiation message's "Measurement Filter Coefficient" information element (IE). The value specified in this IE is controlled with the PtxMeasFilterCoeff parameter.

The RNC furthermore sends the Nokia-proprietary NBAP:Radio Resource Measurement Initiation message to the WBTS to control the reporting period of the cell-level measurements used by PS streaming, indicated by the RRIndPeriod parameter. The WBTS can however filter the measured values obtained in the PtxHSProBR and PtxHSRePo measurements with defined limits. The maximum number of consecutive filtered measurement reports is set to a fixed value of nine (9) periods. If no new measurement result is received from the WBTS, the RNC uses the result previously received.

The RNC does neither average nor estimate the HS-DSCH provided bit rate and HS-DSCH required power for the following reasons: as measurement periods can be quite long, averaging has to rely on estimated values. Estimation, in turn, is however not possible in the RNC because HSPA scheduling is performed by the BTS rather than the RNC.

PS NRT RAB reconfiguration

Basically, RAB reconfiguration can be requested by the SGSN or by the UE. Toward the RAN, the modification is triggered by the core network, signalled through a RANAP: RAB Assignment Request message. The RAB identifier (ID) contained in this message uniquely identifies the RAB to be modified, where several RAB IDs can be transmitted within one RANAP: RAB Assignment Request message.

For interactive and background traffic class RABs, the following RAB parameters can thus be changed:

• Traffic class (TC), from interactive to background and vice-versa
• Maximum bit rate (MBR) for uplink (UL) and downlink (DL)
• Traffic handling priority (THP) of an interactive RAB
• Allocation and retention priority (ARP)

If modification of any parameter other than the above-mentioned RAB parameters is requested, the RNC responds via a RANAP: RAB Assignment Response message with cause code set to Invalid RAB Parameters Combination.

Depending on the UE's current state, the type of request (downgrade or upgrade of QoS parameters), and whether the UE is using DCH or HSPA service, the RNC individually handles the particular PS NRT RAB reconfiguration request.

When a particular UE is in CELL_DCH state, using HSPA service, and modification of QoS parameters is requested, the new RAB parameters are taken into use immediately. The RNC thus matches the RAB's QoS parameters to a QoS priority mapping as is done for the QoSPriorityMapping management parameter, see table Default values of theQoSPriorityMapping parameters.

Before RAB modification is actually started, however, the RNC checks whether or not PS NRT RAB reconfiguration is supported in the BTS, verifying theNodeBRABReconfigSupport parameter. This check is only necessary in case of HSPA connections because the BTS is responsible for HSPA scheduling. Depending on the configuration, the BTSes with the following roles have to support PS NRT RAB reconfiguration:

• DCH/HS-DSCH configuration: the RNC only has to check the capability of the serving BTS, controlling the serving cell.
• E-DCH/HS-DSCH configuration: the RNC has to check the capability of all BTSes which are involved in the E-DCH active set.

In either case, if the queried BTSes do not support RAB modification, the update of the RAB parameters is stopped. Otherwise, RNC prioritizes the NRT RBs according to their QoS priority values and defines the scheduling priority indicator (SPI) for HSPA connections. The SPI is based on the QoS priority value and the value of the HSPAQoSEnabledparameter.

The following cases thus have to be distinguished:

• RAB's new maximum bit rate (MBR) is smaller than existing bit rate for HSDPA-associated UL DCH
  The HSDPA -associated UL DCH is downgraded to a rate that is both still suitable and equal to or lower than the new maximum bit rate of the RAB.
  • If none of the bit rates are allowed although there is no congestion situation, channel type switch (CTS) to DCH with UL and DL rates greater than 0 kbit/s (DCH >0/>0) is performed.
  • Otherwise, if UL bit rates cannot be assigned due to congestion, the RNC checks the source of congestion.
    If congestion occurred on the RNC's transport network layer, channel type switch (CTS) to DCH >0/>0 is performed.
    If congestion occurred due to any other reason, CTS to DCH 0/0 is done. CTS to DCH 0/0 is only performed when all other RABs assigned to the UE are also on DCH >0/>0. If at least one existing RAB is on DCH 0/0, however, the UE will be switched from CELL_DCH to CELL_FACH state.
• QoS parameter change in case of DCH/HS-DSCH configuration
  If the traffic class (TC) and/or the traffic handling priority (THP) change during DCH/HS-DSCH configuration, a new frame handling priority (FHP) as well as the updated UL DCH load factor will be calculated. During the next scheduling period (radio link reconfiguration), the BTS will also be informed about the changed FHP.

Whether or not particular services, identified by traffic class and traffic handling priority, can use HS-DSCH and E-DCH is defined by the HSDSCHQoSclasses andEDCHQOSClasses management parameters, respectively. As a consequence, CTS to DCH/HS-DSCH is performed if a UE uses HSUPA but HSUPA is not supported with the modified RAB parameter values. In a similar way, CTS to DCH >0/>0 is executed when a UE makes use of HSDPA or HSUPA but HSDPA is no longer allowed after RAB reconfiguration, when the changed values become effective.

If the optional Streaming QoS for HSPA feature is simultaneously active, calculation of the nominal bit rate (NBR) for NRT connections mapped to HSPA transport channels is based on the HSPANBRValues management parameter, see Nominal bit rates for HSDPA non-realtime (NRT) services.

For more information, see PS NRT RAB reconfiguration in and PS NRT RAB reconfiguration in