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:
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:
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
- 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 interfaceWhen 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,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 relocationIn 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
- UE involved relocationIn 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. 2. 3.
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:
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:
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 DCHThe 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 configurationIf 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.
No comments:
Post a Comment