78189437 HSUPA Basic Signaling Flows(1)

Document No. Product Name

Intended Users Product Version

Writing Dept. RAN Maintenance Department

Document Version

HSUPA Basic Signaling Flows

Prepared by Xia Cuichun Date 2006/9/18

Reviewed by Date

Reviewed by Date

Approved by Date

Huawei Technologies Co., Ltd.

All Rights Reserved

Revision History

Date Revision Version

Description Author

2006-9-15 V1.0 Create the document. Xia Cuichun

2006-10-14 V1.1 Add the contents about signaling flows. Xia Cuichun and Ge Liang

2006-11-10 V1.2 Add descriptions about the problems found during the test.

Xia Cuichun

2006-12-19 V1.3 Delete the unnecessary information. Ge Yougong

HSUPA Basic Signaling Flows For internal use

Contents

1 Basic Signaling Flows.............................................................................................................5

1.1 Signaling Flow when the UE Reports the HSUPA Capability .........................................5

1.2 HSUPA Cell Setup Signaling Flow..................................................................................7

1.3 Signaling Flow for Service Setup over the HSUPA Channel...........................................8

1.4 Soft (Softer) Handover Signaling Flow..........................................................................12

1.5 Hard Handover Signaling Flow (E2E/E2D)....................................................................17

2 Appendix 1: HSUPA UE Physical Layer Capability ............................................................20

2012-1-13 Huawei Technologies Proprietary Page 3 of 21


Figures

Figure 1.1The RRC CONNECTION REQUEST message..............................................................5

Figure 1.2The RRC CONNECT SETUP CMP message.................................................................6

Figure 1.3HSUPA cell setup signaling flow..................................................................................7

Figure 1.4Major IEs in the NBAP_PSCH_RECFG_REQ message...............................................8

Figure 1.5IEs in the RL_RECFG_READY message......................................................................9

Figure 1.6E-RNTI in the RB_SETUP message............................................................................10

Figure 1.7MAC-d flow information in the RB_SETUP message...............................................10

Figure 1.8E-DCH information in the RB_SETUP message........................................................11

Figure 1.9HSUPA soft handover signaling flow.........................................................................13

Figure 1.10RG_Combination_Index in the soft handover process .........................................14

Figure 1.11RLS information returned in the NBAP_RL_RECFIG_READY message upon

service setup over the HSUPA channel .....................................................................................15

Figure 1.12RLS information when an E-DCH radio link is added.............................................15

Figure 1.13Serving cell update (physical channel reconfiguration) ........................................16



1 Basic Signaling Flows

1.1 Signaling Flow when the UE Reports the HSUPA Capability

The UE first informs the network whether it supports the HSDPA and HSUPA through

the RRC_CONN_REQUEST message. In 1.1, the UE capability shows this UE

supports both the HS-DSCH and E-DCH. The specific physical layer capability will be

reported in the RRC_CONN_SETUP_CMP message. As shown in 1.1, the UE

downlink HS-DSCH physical layer category is 12.

Figure 1.1 The RRC CONNECTION REQUEST message



Figure 1.2 The RRC CONNECT SETUP CMP message

The E-DCH physical layer category information is contained in the

UE_CAPABILITY_CONTAINER. The UU_UE_CAP_CONTAINER_R6_STRU

generally consists of two parts:

One is the RADIO_ACCESS_CAP of the UE.

UU_UE_RADIO_ACCESS_CAP_V690EXT_STRU UeRadioAccessCapV690ext;

The other is INTER_RAT_UE_RADIO_ACCESS_CAP.

Where, the UeRadioAccessCapV690ext will report whether the UE supports the

E-DCH. If yes, the value of E-DCH category will be reported. Because these

values are stored in the container, they cannot be directly viewed in the message.



1.2 HSUPA Cell Setup Signaling Flow

1.2 shows the complete signaling flow for setting up an HSUPA cell. After the system

information is updated, the RNC sends a PSCH reconfiguration

(NBAP_PSCH_RECFG_REQ) message to the NodeB. The message indicates the E-

AGCH assigned to this cell, the E-RGCH/E-HICH channelisation code number, the

reference RTWP, and the maximum target RTWP. Besides, the RNC also provides

the non-serving EDCH to the total EDCH power ratio as a condition for the non-

serving cell to perform the RG down. 1.2 shows each information element (IE).

Figure 1.3 HSUPA cell setup signaling flow



Figure 1.4 Major IEs in the NBAP_PSCH_RECFG_REQ message

1.3 Signaling Flow for Service Setup over the HSUPA Channel

Generally, the NodeB returns the control information related to the E-DCH to the RNC

through the RL_RECFG_READY message. Such information includes the Primary E-

RNTI used by the E-AGCH, Secondary E-RNTI, the channelisation code, the E-

RGCH/E-HICH signature sequence, and the initial serving grant value.



Figure 1.5 IEs in the RL_RECFG_READY message

Note:

If the RRC is set up on the CCH, NodeB will return the above information in the

RL_SETUP_RESPONSE message.

The RNC informs the UE of the (Primary) E-RNTI newly assigned by the NodeB

through the RB_SETUP message, as shown in 1.3.



Figure 1.6 E-RNTI in the RB_SETUP message

Figure 1.7 MAC-d flow information in the RB_SETUP message



In 1.3, the type of transmission channel added is E-DCH and the TTI is 10ms. The

RVTABLE is used for the HARQ retransmission. The PO of the MAC-d flow is 0dB.

The HARQ can be transmitted for up to eight times. As only one MAC-d flow is

configured, MAC-d flow multiplexing is not involved.

Figure 1.8 E-DCH information in the RB_SETUP message

The following lists explanations of some parameters in Figure 8:

1) E-DPCCH-DPCCH power offset: The value is 5 (15/15), indicating that the

transmit power of the E-DPCCH is the same as that of the DPCCH.

2) Happybit delay timer: The value is 20ms. A smaller value means it is easier to

trigger “Unhappy”.

3) E-TFCI: The value is Table 1, which is generally used when the RLC PDU is set

to 336bit.

4) Reference E-TFCI and PO: There is only one group of reference E-TFCI and PO

here. The settings of these values are very important.



5) Maximum number of channelisation codes supported: The value is 7 here,

representing two SF4 codes.

6) pl-NonMax (Puncturing Limit): The value is 11 here, representing 0.44. At this

puncturing limit, the maximum rate of the uplink MAC layer can reach 1.44Mbps.

7) periodicityOfSchedInfo (Period for sending Scheduling Information): The value is

50ms when there is no grant and 100ms when there is grant. The PO is 6dB.

8) RG threeIndexStep Threshold: The value is 20. TwoIndexStep Threshold: The

value is 25.

9) The initial grant value is calculated by the NodeB according to the user GBR

attributes.

Meanwhile, most of the above information will also be sent to the NodeB through the

RL_RECFG_PREP message.

1.4 Soft (Softer) Handover Signaling Flow

The HSUPA soft handover flow is similar to that in the R99. After the UE reports the

1A measurement report, the RNC sends the active set update command. After the

update is completed, the new cell is added to the active set. Then the UE reports the

1D event and triggers the HSUPA serving cell update. The RNC sends a new

measurement control (RRC_MEAS_CTRL) message and uses the PH_CH_RECFG

message to indicate that an update has been triggered on the UE E-DCH serving cell.

Meanwhile, for the E-RGCH, the RNC needs to point out the combined reference

RLS in the RRC_ACTIVE_SET_UPDATE message, as shown in 1.4.



Figure 1.9 HSUPA soft handover signaling flow



Figure 1.10 RG_Combination_Index in the soft handover process

RG_Combination_Index indicates that the UE combines the E-RGCHs of all the cells

belonging to the same serving RLS. The flow is described as follows: The UE

originates the service in the serving cell. The NodeB returns the RLS information of

the E-DCH radio link that is set up in the RL_RECFG_READY message. When a new

link is added, NodeB also returns the RLS information of the new E-DCH radio link.

Based on such information, the RNC indicates the RG_Combination_Index in the

RRC_ACTIVE_SET_UPDATE message. According to this index, the UE combines

the RG information of the cells that belong to this serving RLS.



Figure 1.11 RLS information returned in the NBAP_RL_RECFIG_READY message

upon service setup over the HSUPA channel

Figure 1.12 RLS information when an E-DCH radio link is added



Figure 1.13 Serving cell update (physical channel reconfiguration)

In 1.4, the RNC uses the PCH reconfiguration command to change the 230 cell into

the E-DCH non-serving cell and meanwhile indicates that the 233 cell has been

changed into an E-DCH serving cell.



Note:

For Huawei products, the condition for triggering the HS-DSCH serving cell update

and E-DCH serving cell update is that the UE reports the 1D event.

As the DCH is still used at the downlink direction during the test, the HS-DSCH

serving cell attribute of both the source cell and the target cell is FALSE. In the future,

using HSDPA and HSUPA jointly to carry services will become a mainstream

application. In this case, the HS-DSCH and E-DCH serving cell attributes will be

updated at the same time.

The following explains the relationship between an HSUPA cell and a non-HSUPA cell

in the soft handover process:

When the new target cell does not support the HSUPA or supports HSUPA but

the admission fails, the target cell will be added to the active set. After the

successful addition, the RNC will reconfigure the E-DCH radio link of the source

cell as a DCH.

If the non-HSUPA cells in the active set are removed (that is, all cells in the

active set supports the HSUPA), an attempt will be made to reconfigure the DCH

radio link over the E-DCH.

1.5 Hard Handover Signaling Flow (E2E/E2D)

At present, because no UE supports the compressed mode under the HSUPA, the

inter-frequency hard handover is not tested yet. The following figures related to the

hard handover are the simulation result by using the TTCN.



The compressed mode is started.

The compressed mode is stopped.

The contents of the RRC_PH_CH_RECFG message are similar to that in the

previous section, except that this message has the extra information related to the

compressed mode. When the UE reports the RRC_PH_CH_RECFG_CMP message

on the new cell, the hard handover flow is ended. This flow is an E2E hard handover

flow. That is, the service stays on the E-DCH before and after the hard handover. The

following explains the E2D hard handover flow.



The compressed mode is started.

The channel type is back to the DCH and the compressed mode is stopped.

The following figure shows the contents of the RB RECFG message:



In the RB MAPPING, the UE uplink channel is back to the DCH and meanwhile the E-

DCH information has been deleted.

2 Appendix 1: HSUPA UE Physical Layer

Capability

The following lists the descriptions about the HSUPA UE physical layer capability in

the 25.306 protocol.



Table 13.1 FDD E-DCH physical layer categories

E-DCH category

Maximum number of E-DCH codes transmitted

Minimum spreading factor

Support for 10 and 2 ms

TTI EDCH

Maximum number of bits

of an E-DCH transport block

transmitted within a 10 ms E-

DCH TTI

Maximum number of bits of an E-DCH

transport block transmitted within a 2 ms E-DCH TTI

Category 1 1 SF4 10 ms TTI only

7110 -

Category 2 2 SF4 10 ms and2 ms TTI

14484 2798


14484 -


20000 5772


20000 -


20000 11484

NOTE: When four codes are transmitted in parallel, two codes shall be transmitted with SF2 and two with SF4.

Note: The E-DCH capability of Qualcomm 7200 is Category 5, that is, the UE

supports 2*SF2 and 10ms TTI.


78189437 HSUPA Basic Signaling Flows(1)

Documents