HSDPA Mobility Enhancement Solution to Support Real-Time Delay Sensitive Services. Concept Document

Transcription

1 3GPP TSG RAN Meeting #27 Tokyo, Japan From 9 th To 12 th March 2005 RP Agenda Item: 9.8 Source: Title: Cingular Wireless, Lucent Technologies HSDPA Mobility Enhancement Solution to Support Real-Time Delay Sensitive Services Document for: Information 1. Background/Introduction Concept Document The High Speed Downlink Packet Access (HSDPA) channel was a significant feature introduced by 3GPP in Rel 5. HSDPA provides up to a five-fold improvement in data spectral efficiency over Rel 99 [1] in the downlink. The Enhanced Dedicated Channel (E-DCH) is a significant feature being introduced in 3GPP Rel 6 that provides similar enhancements in the uplink. The combination of HSDPA and E-DCH provides very efficient, symmetric packet data capabilities in UMTS, particularly for best effort data applications. However, many important applications are real-time and delay sensitive in nature (e.g. VoIP and gaming). While HSDPA and E-DCH are capable of supporting applications like VoIP and gaming in a spectrally efficient manner (discussed below), these channels did not consider the quality requirements of such applications, particularly from a handover perspective. The real-time, delay sensitive nature of applications such as VoIP and gaming leads to very robust and timely handover requirements to maintain quality during the handover period. The R 99 Dedicated Channel (DCH) implements Soft Handover (SHO) to accommodate the handover needs of services like voice and gaming. Fortunately, the E-DCH feature also supports SHO (i.e. frame selection) in the uplink and thus should be capable of supporting handover for services like VoIP. However, the HSDPA feature does not support soft handover (i.e. on the HS-DSCH), and thus there is potential quality degradation for services such as VoIP caused by the latency associated with hard handover. Analysis has shown that the delays associated with the hard handover process in Rel 5/Rel 6 HSDPA are excessive (>> 500 ms). The latency associated with layer 3 signaling coupled with the lack of advanced notification of the exact handover time are the key limitations associated with Rel 5/Rel 6 hard handover. This document proposes the introduction of a HSDPA Mobility Enhancement (HME) feature for the support of real-time, delay sensitive applications such as VoIP over the HSDPA channel. The goal of an HME scheme is to speed up the hard handover procedure for HSDPA. This document outlines one example HME solution that can accomplish the goal of reducing handover latency to accommodate VoIP, however it is recognized that other solutions may exist and could be considered. The example HME scheme given in this document uses Layer-1 signaling through the air interface and Iub/Iur user plane framing protocol to request (UE) and confirm (RNC) the handover to the best cell. It is based on the Fast Cell Selection (FCS) concept that was first proposed in the scope of the HSDPA feasibility study and is making use of signaling capabilities already used for Site Selection Diversity Transmission (SSDT). However, contrary to the original FCS proposal, the primary intent is not to generate macro-diversity gain, but to significantly reduce the delay required to execute an HSDPA Cell Change. The Layer 1 signaling provides advanced notification of the exact handover time given the RNC grants the handover. In this way, the new NodeB can prepare for the handover while data traffic is still being sent to the UE on the old leg. The example HME scheme also suggests system pre-configurations in the resource management in order to allow fast cell change after the RNC confirms the handover. The example HME scheme is capable of reducing the latency associated with hard handover to < 100 ms. This reduction in handover latency compared to Rel 5/Rel 6 hard handover will benefit all applications, but is particularly critical for maintaining quality during handover for real-time delay sensitive services like VoIP. V1.4 Page: 1/8

2 2. Market need / benefits Some of the most compelling applications for wireless data are real-time and delay sensitive in nature. In particular, VoIP is an extremely important application to consider given the recent momentum around VoIP and the benefits that VoIP provides in the efficient support of Simultaneous Voice & Data (SVD) services. Gaming is just one example of an SVD service that wireless operators view as having significant new revenue generating potential for wireless data. SVD services can be supported in the current 3GPP standards. Radio Access Bearer (RAB) combinations have been defined that combine the R 99 DCH channels for voice with the Rel 5 HSDPA channels for data. Still, there are several advantages that can be offered by an HSDPA technology supporting VoIP. One advantage of VoIP on HSDPA is that it has potential voice quality benefits compared to VoIP on R 99 DCH channels. This is due to the fast retransmission capabilities of the HSPDA channel which guarantees that nearly all speech frames will be successfully decoded eventually. Through adaptive jitter buffering at the VoIP receiver, it is possible to tradeoff increased delay for improved voice quality for UEs that enter poor RF conditions. Oftentimes, increased delay is a preferable degradation than reduced voice quality, which can lead to muting and even call dropping. Such delay vs. voice quality tradeoffs is not possible with R 99 DCH channels. Another advantage of VoIP on HSDPA is that it is the first step towards realizing the long-term vision of an all-ip packet network supporting all voice and data applications. Being able to support all voice and data applications on an all-ip packet network, using HSDPA for instance, can greatly reduces operational expenses by having a single packet voice/data network to engineer as opposed to engineering both a circuit voice and packet data network. It should also be recognized that several competitive technologies are aggressively working to support high quality VoIP over efficient packet channels already. 1xEV-DO has introduced several enhancements in Rev. A to support VoIP. Not only does 1xEV-DO Rev. A support an enhanced uplink, but it has also introduced the Data Source Channel (DSC) which defines layer 1 signaling for the support of fast handover. Likewise, the WiMAX technology (through e) has defined a Fast Base Station Selection (FBSS) feature to support fast handover. The fast handover benefits of the DSC feature in 1xEV-DO and the FBSS feature in WiMAX is exactly the type of fast handover capability that HSDPA is lacking. 3. HSDPA Handover Delay Event 1D UE TX Event 1D RNC RX Activation CFN Good CQI T Poor CQI TX Gap E G P D t Figure 1. HSDPA Handover Delay with Mixed CQI after Cell Change Event Trigger Event 1D UE TX Event 1D RNC RX Activation CFN T Good CQI Poor CQI TX Gap P D t E Figure 2. HSDPA Handover Delay with Poor CQI after Cell Change Event Trigger. V1.4 Page: 2/8

3 Event 1D UE TX Event 1D RNC RX Activation CFN Good CQI T TX Gap G D t E Figure 3. HSDPA Handover Delay with Good CQI after Cell Change Event Trigger. Best Cell ID UE TX Best Cell ID RNC Notified Cell ID Repitition Period Activation CFN Good CQI T TX Gap Goal of HME G D t E Figure 4. HSDPA Handover Delay with HME and Good CQI after Best Cell ID Determination. 4. HSDPA Handover Delay Definition The total HSDPA handover delay (T ) is illustrated in Figures 1-4 and defined in Equationl1. T = G + P + D (1) The duration between the Cell Change Event Trigger (Event 1D in figures 1-3 above) at the UE and the detection of Event Trigger at the RNC is given by E. Following an Event Trigger and prior to the Activation CFN, the CQI for a user may be good (for duration G ) or poor (for duration P ). 1 By definition, the good CQI duration G and the poor CQI duration P cannot exceed the total handover time as expressed in Equations 2 and 3. 0 G < T (2) 0 P < T (3) Prior to the Activation CFN, the RNC will redirect the UE MAC-d flow from the serving NodeB to the target NodeB; thus, a TX gap ( D ) may exist. 2 Since the RNC will not redirect the MAC-d flow from the serving NodeB to the target NodeBuntil some time after the RNC receives the Event Trigger notification, the maximum value for a TX gap (if one exists) is limited according to Equation 4. 0 D < T E (4) 5. HSDPA Handover Delay Implications The best user-perceived QoS occurs when the total handover delay, T, is equal to G. In this case, the MAC-d flow does not incur any error (due to poor CQI) and incurs the least possible delay (due to MAC-d flow redirection from the serving NodeB to the target NodeB). Poor user-perceived QoS is likely when the total handover delay, T, is dominated by P and D. 3 D is influenced primarily by the RAN 1 Good CQI corresponds to conditions for which a UE MAC-hs can complete a HARQ process, and poor CQI corresponds to conditions for which a UE MAC-hs cannot complete a HARQ process. The boundary between good and bad is primarily a function of the RF environment (e.g., multipath profile), system loading and to a lesser degree the specific MAC-hs scheduling algorithm. 2 The likelihood and duration of a TX gap is a function of the RNC implementation (i.e., the time at which the MAC-d flow is redirected from the serving NodeB to the target NodeB), the NodeB implementation (flow control request), CQI, system loading, and the specific MAC-hs scheduling algorithm. Also, the timing offset between the DPCH and the HS-PDSCH may contribute to the gap [2] 3 P and D are correlated values. V1.4 Page: 3/8

4 implementation. 2 When the MAC-d flow contains data and D is greater than zero, the MAC-d flow incurs additional delay. When the MAC-d flow contains data and P is greater than zero, the MAC-d flow incurs service interruption. P is influenced by less controllable factors. Thus, the goal of HME is to reduce the total handover delay, T, so that the potential impact of P is also reduced. 6. HSDPA Handover Performance The HSDPA handover performance is given in Table 1 for three cases: (1) R6, (2) R6 with the CR presented in [3], and (3) with the HME proposal. The service interruption duration is the time during which data may be lost and is defined as the portion of T for which P 0. The realized delay is the delay incurred by a MAC-d flow due to packet loss or MAC-d flow redirection from the serving NodeB to the target NodeB or the time for UE to reconfigure for the new cell and is defined as P + D. 4 The performance considerations are made with the following assumptions: 1. The delay incurred prior to Cell Change Event Trigger is negligible, 2. The jitter incurred prior to Cell Change Event Trigger is negligible, and 3. The delay incurred in the target NodeB (e.g., due to scheduling delay or CQI) after the Activation CFN is negligible. These assumptions are optimistic but restrict the performance considerations to the period between the UE Event Trigger and the Activation CFN. For ranges given in Table 1, the minimum values are determined when the CQI is only good (i.e., P 0 ). The maximum values are determined when the CQI is only poor (i.e., G = 0 ). All values are determined with a TX gap of 20 ms ( D 20 ms). = HSDPA Handover Performance Total Delay Service Interruption Duration Realized Delay R ms ms ms R6 with CR In Tdoc R ms ms ms With HME ms 0-80 ms ms NOTES: 1. In many cases, the realized delay contributes excessively to the end-to-end delay (and even exceeds the maximum acceptable end-to-end delay) for critical real-time services (e.g., VoIP). 2. For multimedia services, increased service interruption will cause a loss in decoder state synchronization for mechanisms such as ROHC, MPEG, and AMR. Neither the data RAB nor the signaling RAB is required to change during any of the HSDPA handover schemes. Table 1. HSDPA Handover Performance. 7 Outline of one solution approach This section outlines one example HME solution for reducing hard handover latency on HSDPA. The example HME scheme for HSDPA fast handover impacts the following areas; RRC protocol changes to allow configuration of the UE measurements, L-1 signaling through the DPCCH control channel in the air interface, user plane protocol to signal the best cell and for the handover of the Iub/Iur transport, and NBAP/RNSAP protocol changes to allow pre-configuration of NodeBs in the active set. The measurement to determine the best cell is a UE internal measurement and similar to the current Event 1D best cell selection measurement for the HSDPA handover. The averaging characteristics of the UE measurements should be configurable through RRC signaling at the beginning of an HSDPA session. An offset between the best cell and non-best cells should also be configurable independently through RRC using a hysteresis parameter to minimize ping-pong between NodeBs in the active set. Once the measurement indicates a change of the best cell, the example HME scheme requires the UE to repeatedly report the new best cell ID over a pre-defined time interval (preconfigured through RRC signaling) = 4 The realized delay can be expressed equivalently as the portion of the handover delay for which the CQI is not good. V1.4 Page: 4/8

5 as the handover request. The time interval of the cell ID is sufficient with low report rate (around Hz). The temporary cell identification defined in of TS could be re-used as the cell ID for the HME. The NodeBs then report any requested cell change back to the RNC and the RNC either acknowledges the cell handover or may decide not to acknowledge the handover (e.g. if it receives conflicting reports from multiple NodeBs). The UE will attempt to handover to the new best cell at the end of the pre-defined time interval. If the RNC decides that the UE should perform the handover, the UE would be confirmed of it s request to handover to the reported new best cell ID through HS-SCCH scheduling (implicitly) on the new cell at the end of the pre-defined time interval. In this way, the NodeBs and RNC are given advanced notification of the exact time at which the UE will handover (if the UE receives the handover confirmation) in order to prepare the radio links and data flow at the new NodeB. During the transition period between the reported best cell change and the completion of the handover, the current serving cell would continue to schedule the service to the UE and to complete all HARQ processes. This will prevent long periods of time of service interruption. If the network chose to reject the HO request then the RNC will continue to send data through the old cell and the UE will fall back to the old cell. Figure 5 shows the timing diagram for the implicit signaling method of HO confirmation. At the beginning of the Repetition Period 2 in Figure 5, the UE starts reporting Cell ID B as the Best Cell. All Node Bs detect the change of the Cell ID from the cell A to the cell B as the indication of UE s handover request. All the Node Bs report the HO request to the RNC. The RNC will respond its HO decision to the Node B using the Iub Framing Proctol and re-direct the MAC-d PDU to the designated Node B. At the beginning of the Repetition Period 3 in Figure 5, the designated Cell then schedule to the specific UE as the handover response and the UE will monitor two HS-SCCHs from Cell A and two HS-SCCHs from Cell B. The UE also report the CQI for the Cell A in odd number of TTI and the CQI for the Cell B in even number of TTI.. After the UE receives the HS-SCCH scheduling from the specific Cell, the UE will report the CQI to the specific Cell who scheduled it. In case of the first attempt of the UE s HO request being denied, the UE will continue re-request the HO to the target cell B. Serving Cell: A Target Cell: B UE dual monitoring period HO request period t Repetition Period 1 Repetition Period 2 Repetition Period 3 Repetition Period 4 Repetition Period 5 Handover Successful CQI =A, Cell-ID=A CQI =A, Cell-ID=B Odd TTI: CQI=A Even TTI: CQI=B Cell ID = B CQI=B Cell ID= B CQI =B, Cell-ID=B CQI =B, Cell-ID=B HS-SCCH indication from serving cell B Handover Reject during period 3 CQI =A, Cell-ID=A CQI =A, Cell-ID=B Odd TTI: CQI=A Even TTI: CQI=B Cell ID = B CQI=A Cell ID= B Odd TTI: CQI=A Even TTI: CQI=B Cell ID = B HS-SCCH indication from serving cell A CQI=B Cell ID= B CQI =B, Cell-ID=B HS-SCCH indication from serving cell B UE triggers HO request Node Bs detect UE s HO request and send to the RNC RNC responds its HO decision New serving Node B schedules the specific UE as the HO response Figure 5: Timing for the Implicit Signaling of HO confirmation V1.4 Page: 5/8

6 In the Iub/Iur interface, the NodeB and RNC will use user plane signalling to indicate the change of the best cell and to assist the handover of the data transport from RNC! serving NodeB to RNC! target NodeB. The NodeB will signal if the UE requests a Best cell different from the current cell to the RNC through new user plane control frames. The RNC will make the HS-DSCH serving cell change decision based upon reports received by all cells and forward the decision to the all the pre-configured NodeBs through the user plane framing protocol. If the UE s request of the best cell change to the target cell is granted by the RNC, the RNC will re-route the MAC-d data flow to the new target cell in just in advance of the handover time. In order to support the fast HSDPA handover through L-1 signalling, the NodeB/DRNC resources and Iub/Iur links of all cells in the active set to be considered for HME need to be pre-configured and set up in advance of the handover, which allows the RNC to set up the Iub/Iur transport resources for the HS-DSCH in the potential cells. In addition, the RNC would signal to the UE information on the cell IDs to be considered for fast cell selection along with HS-DSCH configuration information associated with them. The three major areas of the example HME scheme for fast HSDPA handover should be distributed to three RAN working groups. The following summarizes the areas of work expected in each RAN area to support the example HME feature: 7.1 HME for fast HSDPA handover in RAN1 L-1 signaling through DPCCH for the indication of the best cell and the request of the HSDPA handover: The FBI bits in the UL DPCCH slot formats 2, 3, 4, and 5 TS and temporary cell ID structure would be used for the UE to report the best cell, thereby requesting handover if the current cell ID is different than the reported best cell ID. Specifically, Event-1D type Best Cell Selection measurement called Event HME Trigger as the reference of the HSDPA best cell the best HSDPA cell is determined by a similar criteria to the Event-1D best cell selection TS for the current HSDPA handover. The measurement is a UE internal measurement and is sent to the NodeB. The offset of the current best cell and non-best cells could be set independently through RRC for optimization. Report the change of the best cell ID and request HSDPA handover in advance of the cell handover - The UE would begin reporting the new cell-id and request HSDPA handover one repetition period of time (N radio frames) in advance before the actual handover. The CQI report will change to be associated with the new cell at the start of the next repetition period if the handover request is granted by the RNC. The serving NodeB continues scheduling service to the UE up to the handover time (end of the Nth frame), and possibly beyond the handover time in case the RNC denies the handover request. Accumulation of repetitive cell-id s during a repetition period and synchronous handover opportunities - The current temperate cell ID through FBI bits defined in tables 3 and 4 of TS contains Long, Medium, or Short ID codes to represent up to 8 cells in the active set. The example HME scheme will have a long repetition period, proposed to be N-frames and set by L-3 reconfiguration messages at session initiation, where the UE is required to indicate a single best cell ID. The best cell ID will repeat within the repetition period. Reporting of the current serving cell ID would indicate no handover request while reporting of a cell ID other than the current serving cell ID would indicate the request to handover. Such reporting would be sent to all NodeBs currently in the active set. All NodeBs in the active set would accumulate the repetitive cell ID reports to improve the reliability of correct detection of the received cell ID. It is desired to complete the detection of a new cell ID, feedback the new cell ID to the RNC, and receive confirmation from the RNC to perform the handover within the repetition period of N frames at a synchronized opportunity. Thus, the accumulation of the received cell ID would be shorter than the repetition period to allow time for other processes in the handover procedures. This synchronizes the handover operation and allows for the opportunity to pre-configure resources, since the RNC and NodeBs know in advance the exact time at which the UE will handover if the UE s handover request is granted by the RNC. Decision notification of handover: The UTRAN makes the final decision of the handover after the L-1 signalling is received from all NodeBs. The notification of the UTRAN decision to the UE could be informed implicitly as follows: V1.4 Page: 6/8

7 Implicit method through HS-SCCH: If the RNC decides to confirm the handover request (and thus HS- DSCH cell change is required), the RNC signals this to all NodeBs through the Iub/Iur Frame protocol. The Target NodeB will receive the MAC-hs data flow where it will then inform the UE of the HS-DSCH data in the new cell through the HS-SCCH once the service is scheduled. If the handover request is not granted by the RNC, the RNC will continue to route the data to the serving NodeB. The serving NodeB would continue scheduling the UE, even after the tentative handover time (i.e. the end of the Nth frame). Thus, the UE needs to monitor two HS-SCCHs in the current serving cell and two HS-SCCHs in the target cell, starting from the next repetition period after the change of the best cell is reported, to accommodate for the successful and failure cases of the handover response. The UE also sends the CQI reports to both NodeBs during this interval. The UE will report the CQI results from both the serving cell and target cell alternatively in every 2-ms TTI starting from the tentative handover time in order to allow either cell as the serving cell to schedule service. The UE will send a CQI report only to the new NodeB once it received scheduled data transmission from the new NodeB (either the target NodeB for the successful handover case or the source NodeB for the failure case). 7.2 System Pre-configuration for HME in RAN2 The HSDPA system information and the Iub/Iur links for all cells in the active set need to be pre-configured in order to quickly respond to the UE L-1 signalling handover request. The pre-configuration is performed by the NBAP and RNSAP protocols towards NodeB cells with radio links on the associated DCH. The preconfiguration of the Iub/Iur link prepares the necessary HS-DSCH resources in the NodeB/DRNC and completes the procedure for the set up of transport network for reporting the change of the best cell. This prepares all target NodeBs to become the HS-DSCH serving cell upon instruction from the RNC through the user plane protocol. Multiple HSDPA configurations stored at UE - When a soft handover leg is added, the RNC will signal to the UE the following information: The cells that the UE should be monitoring for fast cell selection Cell Change along with the associated cell ID to be reported on the FBI bits. a) The radio channel information (HS-SCCH code numbers, H-RNTI etc) for any new cells to be monitored. b) The expected MAC-hs TSN reset during cell change. The UE will store the HS-SCCH in all cells it is commanded to in the active set during the DPCH soft handover. The stored multiple HSDPA configurations will enable the UE to react fast when radio channel conditions change. In addition, all NodeBs considered as candidate cells for HME cell change are configured with HS-DSCH resources, which will enable the NodeB to report to the RNC the best cell indication received in the FBI bits, and to send HS-DSCH data as commanded by the RNC. Monitor HS-SCCH from both Serving and target NodeBs (Synchronous Handover opportunities) When the implicit handover response is considered, the UE needs to monitor two HS-SCCHs from the current serving cell and two HS-SCCHs from the requested target cell to receive the confirmation of the HSDPA handover as discussed above. The selected two HS-SCCHs in the serving and target cells are preconfigured through L-3 signalling messages. The UE is required to monitor the HS-SCCHs from the serving and target cell for only one repetition period starting from the next repetition period after the change of the best cell ID is first indicated. The UE will report the CQI results from both the serving cell and target cell alternatively in every 2-ms TTI in order to allow either cell as the serving cell to schedule service through HS-DSCH. 7.3 HME for fast handover of the Iub/Iur transport in RAN3 The example HME scheme uses the user plane protocol as the L-1 signalling in the UTRAN to indicate the change of the best cell and the request of the HSDPA handover from the NodeBs to the RNC. The user plane protocol is used to receive the acknowledgement of the HSDPA handover request from the RNC to the NodeBs: " UTRAN pre-configure resources to get ready for the HSDPA serving link handover The UTRAN will pre-configure Iub, Iur, and all network node process resources at the same time as the DCH enters soft handover. In other words, the Iub and Iur RL Radio link Preparation and transport network set up procedures will be set up in advance of the UE signalling a best cell change. Multiple V1.4 Page: 7/8

8 Iub/Iur MAC-d flows are set up but only the primary cell MAC-d flow link is active at a time. This would not increase the backhaul traffic volume. " User Plane Signalling for Backhaul (Iub/Iur Frame Protocol for the HSDPA primary cell indication) Single cast Iub/Iur link with fast handover: The proposal is to enhance the Iub/Iur Frame Protocol to have a new control frame containing the indication of the primary cell/non-primary cell during the handover. The UE would already have stored multiple HSDPA configurations and the UTRAN has already set up the Iub/Iur links for the target cells in the active set. Once the NodeBs receive the cell ID through FBI bits that indicate a change of the HSDPA serving cell, all NodeBs would send a new control frame of the UL Iub/Iur Frame protocol to indicate the change. The RNC would make the decision on the handover request and send the acknowledgement of the new serving cell to all NodeBs through a DL Iub Frame Protocol new control frame. The RNC would start sending the data to the new best cell after the RNC resource management function acknowledges the UE s handover request. 7.4 Implementation in the Standard A set of preliminary CRs were prepared to evaluate the amount and complexity of the modifications that would be required in the various 3GPP specifications to implement the previous HME solution. These draft CRs are attached to this document for information. 8 References: [1] The Evolution of UMTS - 3GPP Release 5 and Beyond, 3Gamerica [2] R , "Clarification on the reconfiguration of HSDPA", Panasonic [3] R , Detection of Activation CFN wraparound in the UE during HS-DSCH cell change, Lucent Technologies. V1.4 Page: 8/8

9 CHANGE REQUEST CR-Form-v4 $ CR CR-xxx $ rev - $ Current version: $ For HELP on using this form, see bottom of this page or look at the pop-up text over the $ symbols. Proposed change affects: $ (U)SIM ME/UE X Radio Access Network X Core Network Title: $ HS-DSCH fast Handover procedure Source: $ Work item code: $ Date: $ Category: $ Release: $ Use one of the following categories: Use one of the following releases: F (correction) 2 (GSM Phase 2) A (corresponds to a correction in an earlier release) R96 (Release 1996) B (addition of feature), R97 (Release 1997) C (functional modification of feature) R98 (Release 1998) D (editorial modification) R99 (Release 1999) Detailed explanations of the above categories can REL-4 (Release 4) be found in 3GPP TR REL-5 (Release 5) REL-6 (Release 6) Reason for change: $ Summary of change: $ Consequences if $ not approved:. Clauses affected: $ Other specs $ Other core specifications $ affected: Test specifications O&M Specifications Other comments: $ How to create CRs using this form: Comprehensive information and tips about how to create CRs can be found at: Below is a brief summary: 1) Fill out the above form. The symbols above marked $ contain pop-up help information about the field that they are closest to. 2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word "revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can be downloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version, look for the directory name with the latest date e.g contains the specifications resulting from the March 2001 TSG meetings. 3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of the clause containing the first piece of changed text. Delete those parts of the specification which are not relevant to the change request. CR page 1

10 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 2 1 Scope The present document specifies and establishes the characteristics of the physicals layer procedures in the FDD mode of UTRA. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies. [1] 3GPP TS : "Physical channels and mapping of transport channels onto physical channels (FDD)". [2] 3GPP TS : "Multiplexing and channel coding (FDD)". [3] 3GPP TS : "Spreading and modulation (FDD)". [4] 3GPP TS : "Physical layer Measurements (FDD)". [5] 3GPP TS : "RRC Protocol Specification".. [6] 3GPP TS : "UTRAN Iub Interface NBAP Signalling". [7] 3GPP TS : "UE Radio transmission and Reception (FDD)". [8] 3GPP TS : "Requirements for Support of Radio Resource Management (FDD)". [9] 3GPP TS : " MAC protocol specification". [10] 3GPP TS25.306: UE Radio Access Capabilities [11] 3GPP TS25.427: :UTRAN Iub/Iur interface user plane protocol for DCH data streams. CR page 2

11 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 3 [ ] 6A 6A.1 HS-DSCH-related procedures General procedure Scheduling and transport format selection is controlled by the MAC-hs sublayer in the Node B [9]. The following physical layer parameters are signalled to the UE and the Node B from higher layers: 1) HS-SCCH set to be monitored 2) Repetition factor of ACK/NACK: N_acknack_transmit 3) Channel Quality Indicator (CQI) feedback cycle k. 4) Repetition factor of CQI: N_cqi_transmit 5) Measurement power offset Γ 6) Status of preamble/postamble transmission: HARQ_preamble_mode 6A.1.1 UE procedure for receiving HS-DSCH In this sub-clause, sub-frame n on the HS-SCCHs refers to the sub-frame which is associated with sub-frame n on the HS-PDSCH as defined in [1], and sub-frame n on the HS-DPCCH refers to the sub-frame which is related to sub-frame n on the HS-PDSCH as defined in [1]. If the UE did not detect consistent control information intended for this UE on any of the HS-SCCHs in the HS- SCCH set in the immediately preceding subframe n 1, the UE shall in sub-frame n monitor all HS-SCCHs in the HS-SCCH set. The maximum size of the HS-SCCH set is 4. In case the HS-DSCH fast handover procedure is actived and if the UE reports a cell in the current repetition period, which is different from the current serving cell, the UE shall monitor in the following repetition period the first two HS-SCCHs out of the HS-SCCH sets of the current serving cell and the reported cell, respectively. If the UE did detect consistent control information intended for this UE in the immediately preceding subframe n 1, it is sufficient in sub-frame n to only monitor the same HS-SCCH used in the immediately preceding subframe n 1. When the UE monitors HS-SCCHs, the UE shall only consider the control information to be consistent if decoded 'channelization-code-set information' is lower than or equal to 'maximum number of HS-DSCH codes received' in its UE capability and if the decoded modulation scheme is valid in terms of its UE capability. If a UE detects that one of the monitored HS-SCCHs in sub-frame n carries consistent control information intended for this UE, the UE shall start receiving the HS-PDSCHs indicated by this control information, and, if HARQ_preamble_mode = 1, the UE shall: transmit a HARQ Preamble (PRE) in the slot allocated to HARQ-ACK in HS-DPCCH sub-frame n 1, unless an ACK or NACK is to be transmitted in sub-frame n 1 as a result of an HS-DSCH transmission earlier than sub-frame n on the HS-PDSCH, and if N_acknack_transmit > 1, the UE shall transmit a HARQ Preamble in the slot allocated to HARQ-ACK in HS- DPCCH sub-frame n 2, unless an ACK or NACK is to be transmitted in sub-frame n 2 as a result of an HS- DSCH transmission earlier than sub-frame n on the HS-PDSCH. The transport block size information shall be derived from the signaled TFRI value as defined in [9]. If the 'Hybrid- ARQ process information' is not included in the set configured by upper layers, the UE shall discard the information received on this HS-SCCH and on the HS-PDSCHs. CR page 3

12 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 4 The UE shall transmit the ACK/NACK information received from MAC-hs in the slot allocated to the HARQ-ACK in the corresponding HS-DPCCH sub-frame as defined in [1]. When N_ acknack_transmit is greater than one, the UE shall: repeat the transmission of the ACK/NACK information over the next (N_ acknack_transmit-1) consecutive HS- DPCCH sub-frames, in the slots allocated to the HARQ-ACK as defined in [1] and not attempt to receive nor decode transport blocks from the HS-PDSCH in HS-DSCH sub-frames corresponding to HS-DPCCH sub-frames in which the ACK/NACK information transmission is repeated. If ACK or NACK is transmitted in HS-DPCCH sub-frame n, and HARQ_preamble_mode = 1 and UE InterTTI N_acknack_transmit, then the UE shall: transmit a HARQ Postamble (POST) in the slot allocated to HARQ-ACK in HS-DPCCH subframe n + 2*N_acknack_transmt 1, unless ACK, NACK, or PRE is to be transmitted in this subframe, and if N_acknack_transmit > 1, transmit a HARQ Postamble (POST) in the slot allocated to HARQ-ACK in HS- DPCCH subframe n + 2*N_acknack_transmit 2, unless an ACK, NACK or PRE is to be transmitted in this subframe. If consistent control information is not detected on any of the HS-SCCHs in the HS-SCCH set, DTX shall be used on the HS-DPCCH in the corresponding HS-DPCCH subframe unless PRE or POST are transmitted as described above. 6A.1.2 UE procedure for reporting channel quality indication (CQI) With the exception of the provisions of subclause 6A.3, the following shall apply: 1) The UE derives the CQI value as defined in 6A.2. 2) For k = 0, the UE shall not transmit the CQI value. For k > 0, the UE shall transmit the CQI value in each subframe that starts m 256 chips after the start of the associated uplink DPCCH frame with m fulfilling ( 5 + m 256chip 7680chip ) mod k = 0 CFN with k = k ( 2ms), where CFN denotes the connection frame number for the associated DPCH and the set of five possible values of m is calculated as described in subclause 7.7 in [1]. 3) The UE shall repeat the transmission of the CQI value derived in 1) over the next (N_cqi_transmit 1) consecutive HS-DPCCH sub frames in the slots respectively allocated to the CQI as defined in [1]. UE does not support the case of k < N _ cqi_ transmit. 4) The UE shall not transmit the CQI in other subframes than those described in 2) and 3). 5) In case the HS-DSCH fast handover procedure is actived and if the UE reports a cell in the current repetition period, which is different from the current serving cell, the UE shall report in the following repetition period alternating CQI for the current serving cell and the reported cell, respectively. The UE shall start with the current serving cell. 6A.2 Channel quality indicator (CQI) definition Based on an unrestricted observation interval, the UE shall report the highest tabulated CQI value for which a single HS-DSCH sub-frame formatted with the transport block size, number of HS-PDSCH codes and modulation corresponding to the reported or lower CQI value could be received in a 3-slot reference period ending 1 slot before the start of the first slot in which the reported CQI value is transmitted and for which the transport block error probability would not exceed 0.1. Depending on the UE category as defined in [10], either Table 7A, 7B, 7C, 7D, or 7E should be used. CR page 4

13 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 5 For the purpose of CQI reporting, the UE shall assume a total received HS-PDSCH power of P P + Γ + in db, HSPDSCH = CPICH where the total received power is evenly distributed among the HS-PDSCH codes of the reported CQI value, the measurement power offset Γ is signaled by higher layers and the reference power adjustment is given by Table 7A, 7B, 7C, 7D, or 7E depending on the UE category. Further, UE shall assume the number of soft channel bits available in the virtual IR buffer (NIR), and redundancy and constellation version parameter (XRV) as given by Table 7A, 7B, 7C, 7D, or 7E depending on the UE category. If higher layer signaling informs the UE that for the radio link from the serving HS-DSCH cell it may use a S-CPICH as a phase reference and the P-CPICH is not a valid phase reference, P CPICH is the received power of the S-CPICH used by the UE, otherwise P CPICH is the received power of the P-CPICH. If closed loop transmit diversity is used for the radio link from the serving HS-DSCH cell, P CPICH denotes the power of the combined received CPICH from both transmit antennas, determined as if error-free transmitter weights had been applied to the CPICH, where those weights are determined as described in sub-clause 7.2. If STTD is used, P CPICH denotes the combined CPICH power received from each transmit antenna and if no transmit diversity is used P CPICH denotes the power received from the non diversity antenna. For the purpose of CQI reporting the UE shall assume that all HS-PDSCH channelisation codes it may receive are under the same scrambling code as the Common Pilot Channel used to determine P CPICH. CR page 5

14 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 6 Table 7A: CQI mapping table for UE categories 1 to 6. CQI value Transport Block Size Number of HS-PDSCH Modulation Reference power adjustment NIR XRV 0 N/A Out of range QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM CR page 6

15 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 7 Table 7B: CQI mapping table for UE categories 7 and 8. CQI value Transport Block Size Number of HS-PDSCH Modulation Reference power adjustment NIR XRV 0 N/A Out of range QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM CR page 7

16 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 8 Table 7C: CQI mapping table for UE category 9. CQI value Transport Block Size Number of HS-PDSCH Modulation Reference power adjustment NIR XRV 0 N/A Out of range QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM CR page 8

17 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 9 Table 7D: CQI mapping table for UE category 10. CQI value Transport Block Size Number of HS-PDSCH Modulation Reference power adjustment NIR XRV 0 N/A Out of range QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM QAM CR page 9

18 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 10 Table 7E: CQI mapping table for UE categories 11 and 12. CQI value Transport Block Size Number of HS-PDSCH Modulation Reference power adjustment NIR XRV 0 N/A Out of range QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK QPSK A.3 Operation during compressed mode on the associated DPCH During compressed mode on the associated DPCH, the following applies for the UE for transmission of HS-DPCCH and reception of HS-SCCH and HS-PDSCH: - The UE shall neglect 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 shall be transmitted by the UE to respond to the corresponding downlink transmission. CR page 10

19 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 11 - If a part of a HS-DPCCH slot allocated to HARQ-ACK overlaps with an uplink transmission gap on the associated DPCH, the UE shall use DTX on the HS-DPCCH in that HS-DPCCH slot. - 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 shall not transmit CQI information in that sub-frame. - If a CQI report is scheduled in the current CQI field according to subclause 6A.1.2 paragraph (2), and the corresponding 3-slot reference period (as defined in subclause 6A.2) wholly or partly overlaps a downlink transmission gap, then the UE shall use DTX in the current CQI field and in the CQI fields in the next (N_cqi_transmit 1) subframes. 6A.4 HS-DSCH fast handover procedure The HS-DSCH fast handover procedure is to use the UL DPCCH control channel to indicate the change of the best cell as the UE s request of the HS-DSCH handover to the new best cell. The operation of the HS-DSCH fast handover is to have the UL DPCCH reconfigured to slot format 2, 3, 4, or 5 [1] with the FBI bits in the beginning of the soft handover of the DCH. A sequence of the FBI bits is used to form the temporary cell ID, as shown in Table 3 and 4, to indicate the best cell of the HS-DSCH. Each cell involved in the soft handover is assigned a temporary cell ID. The UE reports the best cell ID and repeats it for a given repetition period. The repetition period is defined by the repetition period duration N report number of radio frames and the repetition period start reference CFN. They are set through [5] and [6]. The UE shall report in the current repetition period the cell ID of the best cell according to the UE internal measurement result obtained in the previous repetition period.. The Node B needs to decode the cell ID reliably within the given decoding period [6]. Once the change of the best cell is detected, all cells report the change of the best cell to the RNC through the new control frame in [11]. The UE internal measurement to determine the best cell is shown in the following: Triggering condition for the determination of the best cell 10 LogM + CIO 10 LogM + CIO H, NotBest NotBest Best Best + The variables in the formula are defined as follows and given by [5]: M NotBest is the measurement result of a cell among the preconfigured cells for HSDPA not stored in the "best cell". IIR filtering shall be applied as of [5]. The measure can be either CPICH RSCP or CPICH Ec/I0. CIO NotBest is the cell individual offset in db of a cell not stored in the "best cell" for all preconfigured cells for HSDPA.. M Best is the measurement result of the cell stored in the "best cell" IIR filtering shall be applied as of [5]. The measure can be either CPICH RSCP or CPICH Ec/I0. CIO Best is the cell individual offset of a cell stored in the "best cell". H is the hysteresis parameter for the detection of a new best cell. Filtering coefficient, measure, CIO and H are configured by higher layers as of [5]. The HS-DSCH fast handover procedure and CLTD features cannot be used simultaneously. If the network decides that the UE should perform the handover, the UE would be confirmed of it s request to handover to the reported new best cell ID through HS-SCCH scheduling. The UE will attempt to handover to the new best cell at the end of the repetition period of time over which it is required to indicate the new best cell ID. In this way, the NodeBs and RNC are given advanced notification of the exact time at which the UE will handover (if the UE receives the handover confirmation) in order to prepare the radio links and data flow at the new NodeB. During the transition period between the reported best cell change and the completion of the handover, the current serving cell would CR page 11

20 3GPP TS aa.bbb vx.y.z (YYYY-MM) CR page 12 continue to schedule the service to the UE and attempt to complete all HARQ processes. This will prevent long periods of time of service interruption. The notification of the UTRAN decision to the UE is as follows If the RNC decides to confirm the handover request (and thus HS-DSCH cell change is required), the RNC signals this to all NodeBs that contain preconfigured cells for HSDPA through the control frame in [11]. The Target NodeB will receive the MAC-d data flow where it will then schedule to the UE of the HS-DSCH data in the new cell through the HS-SCCH at the start of the Repetition period. If the handover request is not granted by the RNC, the RNC will continue to route the data to the serving NodeB. The serving NodeB would continue scheduling the UE, even after the tentative handover time (i.e. the end of the Nth frame). Thus, the UE needs to monitor two HS-SCCHs in the current serving cell and two HS-SCCHs in the target cell, starting from the next repetition period after the change of the best cell is reported, to accommodate for the successful and failure cases of the handover response, cf section 6A.1.1. The UE also sends the CQI reports to both NodeBs during this period. The UE will report the CQI results from both the serving cell in the odd numbers of TTI and target cell alternatively in the even number of TTIs every subframe starting from the end of the repetition period of the best cell change in order to allow either cell as the serving cell to schedule service, cf. section 6A.1.2. The UE will send a single CQI report only to the new NodeB and monitor HS-SCCHs from one cell once it received scheduled data transmission from the new NodeB (either the target NodeB for the successful handover case or the source NodeB for the failure case) or it received the handover response from the layer 3 signaling message [5]. CR page 12

21 3GPP TSG-??? Meeting #nn Location, Country, Date CHANGE REQUEST Tdoc $DocNumber CR-Form-v7.1 $ CR CRNum $ rev - $ Current version: $ For HELP on using this form, see bottom of this page or look at the pop-up text over the $ symbols. Proposed change affects: UICC apps$ ME X Radio Access Network X Core Network Title: $ HSDPA Fast handover procedure Source: $ Work item code: $ Date: $ dd/mm/yyyy Category: $ Release: $ Use one of the following categories: Use one of the following releases: F (correction) Ph2 (GSM Phase 2) A (corresponds to a correction in an earlier release) R96 (Release 1996) B (addition of feature), R97 (Release 1997) C (functional modification of feature) R98 (Release 1998) D (editorial modification) R99 (Release 1999) Detailed explanations of the above categories can Rel-4 (Release 4) be found in 3GPP TR Rel-5 (Release 5) Rel-6 (Release 6) Rel-7 (Release 7) Reason for change: $ Summary of change: $ Consequences if $ not approved: Clauses affected: $ Y N Other specs $ Other core specifications $ affected: Test specifications O&M Specifications Other comments: $ How to create CRs using this form: Comprehensive information and tips about how to create CRs can be found at Below is a brief summary: 1) Fill out the above form. The symbols above marked $ contain pop-up help information about the field that they are closest to. 2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word "revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can be downloaded from the 3GPP server under ftp://ftp.3gpp.org/specs/ For the latest version, look for the directory name with the latest date e.g contains the specifications resulting from the March 2001 TSG meetings. CR page 1