5 Data Streams User Plane Procedures
25.4353GPPRelease 17TSUTRAN Iub interface user plane protocols for Common Transport Channel data streams
5.1 Data Transfer
5.1.1 RACH Channels
Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC. Data Transfer procedure consists of a transmission of Data Frame from Node B to CRNC.
Figure 1: RACH Data Transfer procedure
5.1.2 CPCH Channels [FDD]
Void.
5.1.3 Secondary-CCPCH related transport Channels
For the FACH transport channel, a Data Transfer procedure is used to transfer data from CRNC to Node B. Data Transfer procedure consists of a transmission of Data Frame from CRNC to Node B.
Figure 3: FACH Data Transfer procedure
For the PCH transport channel, a Data Transfer procedure is used to transfer data from CRNC to Node B. Data Transfer procedure consists of a transmission of Data Frame from CRNC to Node B.
Figure 4: PCH Data Transfer procedure
In this case the PCH DATA FRAME may also transport information related to the PICH channel.
If the Node B does not receive a valid FP frame in a TTI, it assumes that there is no data to be transmitted in that TTI for this transport channel. For the FACH and PCH transport channels, the TFS shall never define a Transport Block Size of zero bits.
If the Node B is aware of a TFI value corresponding to zero bits for this transport channel, this TFI is assumed. When combining the TFI’s of the different transport channels, a valid TFCI might result and in this case data shall be transmitted on the Uu.
If the Node B is not aware of a TFI value corresponding to zero bits for this transport channel or if combining the TFI corresponding to zero bits with other TFI’s results in an unknown TFI combination, the handling as described in the following paragraph shall be applied.
At each frame, the Node B shall build the TFCI value of each secondary-CCPCH according to the TFIs of the transport channels multiplexed on this secondary-CCPCH and scheduled for that frame. [FDD – In case the Node B receives an unknown TFI combination, no pilot bits, TFCI bits or Data bits shall be transmitted.] [TDD – In case the Node B receives an unknown TFI combination, it shall apply DTX, i.e. suspend transmission on the corresponding S-CCPCH – except if this S-CCPCH provides the "beacon function", in which case the Node B shall maintain the physical layer transmission as specified in TS 25.221] [4].
If the Node B does not receive a valid FP frame in a TTI or a frame without paging indication information, it assumes that no UE’s have to be paged on the Uu in this TTI. In this case the default PICH bit pattern of all zeros shall be transmitted.
Data Frames sent on Iub for different transport channels multiplexed on one secondary-CCPCH might indicate different transmission power levels to be used in a certain Uu frame. Node-B shall determine the highest DL power level required for any of the transport channels multiplexed in a certain Uu frame and use this power level as the desired output level for the data.
In the case there is no data (i.e. no TB in the FP frame or no FP frame) in any transport channel for a given TTI and a TFCI is defined for no transmission on all transport channels multiplexed on the S-CCPCH, the TFCI transmit power is unspecified.
NOTE: It can be for example 0 or determined by the Node B relatively to Pref-nodata = Min (PCH Power, Max FACH1 Power, Max FACH2 Power, …., Max FACHn Power) where PCH, FACH1, FACH2, …, FACHn are the transport channels of the S-CCPCH [FDD , using the respective PO1 and PO3 offsets specified in TS 25.214 [10]].
5.1.4 Downlink Shared Channels [TDD]
The Data Transfer procedure is used to transfer a DSCH DATA FRAME from the CRNC to a Node B.
If the Node B does not receive a valid DSCH DATA FRAME for transmission in a given TTI, it assumes that there is no data to be transmitted in that TTI for this transport channel. For the DSCH transport channel, the TFS shall never define a Transport Block Size of zero bits.
The Node B shall use the header information in the DSCH DATA FRAME to determine which PDSCH Set [3.84Mcps and 7.68 Mcps TDD – and Transmit Power Level if no closed loop TPC power control is used] should be used in the PDSCH Uu frames associated to the specified CFN. The specified PDSCH Set [3.84Mcps and 7.68 Mcps TDD – and Transmit Power Level if no closed loop TPC power control is used] shall then be used for DSCH transmission for as long as there is data to transmit or until a new DSCH DATA FRAME arrives that specifies that a different PDSCH Set [3.84Mcps and 7.68 Mcps TDD – and/or Transmit Power Level if no closed loop TPC power control is used] should be used. This feature enables multiple DSCH’s with different TTI to be supported.
The Node B may receive a DSCH data frame which contains a TFI value corresponding to there being no data to transmit, such a DSCH DATA FRAME will have no transport blocks. On receiving such a DATA FRAME the Node B shall apply the specified PDSCH Set [3.84Mcps and 7.68 Mcps TDD – and Transmit Power Level if no closed loop TPC power control is used] as described above starting in the PDSCH Uu frame associated to the specified CFN. This feature enables multiple DSCH’s with different TTI to be supported, the use of such a zero payload DSCH DATA FRAME solves the problem of how the Node B should determine what PDSCH Set [3.84Mcps and 7.68 Mcps TDD – and Transmit Power Level if no closed loop TPC power control is used] should be used in the event that transmission of a transport block set being transmitted with a short TTI comes to an end, whilst the transmission of a TBS with a long TTI continues.
Data Frames sent on Iub for different DSCH transport channels multiplexed on one CCTrCH might indicate different transmission power levels to be used in a certain Uu frame. Node-B shall determine the highest DL power level required for any of the transport channels multiplexed in a certain Uu frame and use this power level as the desired output level.
Figure 5: DSCH Data Transfer procedure
5.1.5 Uplink Shared Channels [TDD]
Data Transfer procedure is used to transfer data received from Uu interface from Node B to CRNC. Data Transfer procedure consists of a transmission of Data Frame from Node B to CRNC.
Figure 6: USCH Data Transfer procedure
Node B shall always send an USCH DATA FRAME to the CRNC provided the Transport Format addressed by the TFI indicates that the number of Transport Blocks is greater than 0.
When UL synchronisation is lost or not yet achieved on the Uu, USCH DATA FRAMEs shall not be sent to the CRNC.
When Node B receives an invalid TFCI in the PUSCH, USCH DATA FRAMEs shall not be sent to the CRNC.
5.1.6 High Speed Downlink Shared Channels
The Data Transfer procedure is used to transfer a HS-DSCH DATA FRAME (TYPE 1, TYPE 2 [FDD and 1.28Mcps TDD – or TYPE3]) from the CRNC to a Node B. HS-DSCH DATA FRAME TYPE 2 is selected if the IE HS-DSCH MAC-d PDU Size Format in NBAP (TS 25.433 [6]) is present and set to ‘Flexible MAC-d PDU Size’ [FDD and 1.28Mcps TDD – or if the IE HS-DSCH Common System Information is present and the UE is in Cell_FACH state. HS-DSCH DATA FRAME TYPE 3 is selected if the IE HS-DSCH Paging System Information in NBAP (TS 25.433 [6]) is present and the UE is in Cell_PCH state or URA_PCH state]. HS-DSCH DATA FRAME TYPE 1 is selected in any other case.
[FDD and 1.28Mcps TDD – Three types of HS-DSCH Frame Protocols exist for HS-DSCH data transfer procedure, i.e., HS-DSCH Frame Protocol TYPE 1 (including HS-DSCH DATA FRAME TYPE 1 and HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame), HS-DSCH Frame Protocol TYPE 2 (including HS-DSCH DATA FRAME TYPE 2 and HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame) and HS-DSCH Frame Protocol TYPE 3 (including HS-DSCH DATA FRAME TYPE 3).]
[3.84Mcps TDD and 7.68 Mcps TDD – Two types of HS-DSCH Frame Protocols exist for HS-DSCH data transfer procedure, i.e., HS-DSCH Frame Protocol TYPE 1 (including HS-DSCH DATA FRAME TYPE 1 and HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame) and HS-DSCH Frame Protocol TYPE 2 (including HS-DSCH DATA FRAME TYPE 2 and HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame).]
HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame shall be associated only with HS-DSCH DATA FRAME TYPE 1 while HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame shall be associated only with HS-DSCH DATA FRAME TYPE 2. HS-DSCH CAPACITY REQUEST Control Frame shall be used for both of HS-DSCH Frame Protocols. HS-DSCH Frame Protocol TYPE 2 is used for Flexible MAC-d PDU Size [FDD and 1.28Mcps TDD – and Enhanced Cell_FACH Operation] as described in NBAP (TS 25.433 [6]).
When the CRNC has been granted capacity by the Node B via the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame or via the HS-DSCH initial capacity allocation as described in TS 25.433 [6] and the CRNC has data waiting to be sent, then the HS-DSCH DATA FRAME (TYPE 1 or TYPE 2) is used to transfer the data. If the CRNC has been granted capacity by the Node B via the HS-DSCH initial capacity allocation as described in TS 25.433 [6], this capacity is valid for only the first HS-DSCH DATA FRAME (TYPE 1 or TYPE 2) transmission. If the HS-DSCH Frame Protocol TYPE 2 has been selected by the Node B, the granted capacity shall be interpreted as the total number of octets which is retrieved by multiplying the maximum MAC-d PDU [FDD and 1.28Mcps TDD – or MAC-c PDU] length (indicated by the Maximum MAC-d/c PDU Length IE) with the number of MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs] (indicated by the HS-DSCH Credits IE). When data is waiting to be transferred, and a CAPACITY ALLOCATION (TYPE 1 or TYPE 2) is received, a DATA FRAME (TYPE 1 or TYPE 2) will be transmitted immediately according to allocation received. If the allocation received is >0 but less than the data waiting to be transferred, then the CRNC may send one HS-DSCH DATA FRAME TYPE 2 containing one MAC-d PDU [FDD – or MAC-c PDU] with a length up to the NBAP Maximum MAC-d PDU Size Extended [FDD and 1.28Mcps TDD – or Maximum MAC-c PDU Size] IE value. In such a case, the amount of data exceeding the allocated capacity for the first HS-DSCH Interval shall be credited from the following HS-DSCH Intervals, if available.
In case of HS-DSCH Frame Protocol TYPE 1, multiple MAC-d PDUs of same length and same priority level (CmCH-PI) may be transmitted in one MAC-d flow in the same HS-DSCH DATA FRAME TYPE 1.
In case of HS-DSCH Frame Protocol TYPE 2, MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs] with the same logical channel ID shall be associated to one unique priority level (CmCH-PI).
The HS-DSCH DATA FRAME (TYPE 1 and TYPE 2) includes a User Buffer Size IE to indicate the amount of data pending for the respective MAC-d flow for the indicated priority level. [FDD and 1.28Mcps TDD – The HS-DSCH DATA FRAME TYPE 2 includes PDUs for UE in Cell_FACH includes a User Buffer Size IE to indicate the amount of data pending for the respective Common MAC flow for the indicated priority level.] Within one priority level (CmCH-PI) and size the MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs] shall be transmitted by the Node B on the Uu interface in the same order as they were received from the CRNC.
FDD – In case of HS-DSCH Frame Protocol TYPE 2 or TYPE 3 and when the UE is not in Cell_DCH state, then (see TS 25.331 [8] and TS 25.321 [9]):]
– [FDD – When transmitting the MAC-ehs PDU on the Uu interface using the dedicated H-RNTI for DCCH/DTCH the Node B shall:]
– [FDD – if supported use the actual HS-DSCH physical layer category for MAC-ehs of the UE, or]
– [FDD – if the actual HS-DSCH physical layer category is not known to Node B or the usage of the actual UE category is not supported – use category 12 and limit the MAC-ehs PDU size to not more than 1572 bits, if supported]
– [FDD – When transmitting the MAC-ehs PDU on the Uu interface for other channels than BCCH and not using the dedicated H-RNTI the Node B shall if supported use the "Total number of soft channel bits" as defined for a UE of category 12 (see Table 5.1a in TS 25.306 [12])]
– [FDD – When transmitting the MAC-ehs PDU on the Uu interface for BCCH, the Node B shall, if supported, use category 12 and limit the MAC-ehs PDU size to 1572 bits.]
If the Flush IE in the HS-DSCH DATA FRAME (TYPE 1 and TYPE 2) is set to "flush" the Node B should remove all MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs] from the corresponding MAC-hs Priority Queue that have been received prior to this data frame on the same transport bearer.
For the purpose of TNL Congestion Control on HSDPA, the Frame Sequence Number and the DRT IEs may be included by the CRNC.
Figure 6A: HS-DSCH Data Transfer procedure
5.1.7 E-DCH Channels for CELL_FACH and Idle[FDD and 1.28Mcps TDD]
The E-DCH Data Transfer procedure for CELL_FACH and Idle is used to transfer an E-DCH DATA FRAME from the Node B to the CRNC. The E-DCH user-plane payload is transmitted using the E-DCH DATA FRAME only when some payload has been successfully received in same way as E-DCH Data Transfer procedure for Cell_DCH defined in TS 25.427 [13], i.e., only silent mode defined in TS 25.427 [13] is used.
Figure 6B : E-DCH Enhanced Data Transfer procedure in CELL_FACH and Idle
5.2 Node Synchronisation
In the Node Synchronisation procedure, the RNC sends a DL NODE SYNCHRONISATION control frame to Node B containing the parameter T1. Upon reception of a DL NODE SYNCHRONISATION control frame, the Node B shall respond with UL NODE SYNCHRONISATION control frame, indicating T2 and T3, as well as T1 which was indicated in the initiating DL NODE SYNCHRONISATION control frame.
The T1, T2, T3 parameters are defined as:
T1: RNC specific frame number (RFN) that indicates the time when RNC sends the frame through the SAP to the transport layer.
T2: Node B specific frame number (BFN) that indicates the time when Node B receives the correspondent DL NODE SYNCHRONISATION control frame through the SAP from the transport layer.
T3: Node B specific frame number (BFN) that indicates the time when Node B sends the frame through the SAP to the transport layer.
The general overview on the Node Synchronisation procedure is reported in TS 25.402 [2].
The procedure shall not be applied on transport bearers with IP multicast option.
Figure 7: Node Synchronisation procedure
5.3 DL Transport Channels Synchronisation
CRNC sends a DL SYNCHRONISATION control frame to Node B. This message indicates the target CFN.
Upon reception of the DL SYNCHRONISATION control frame Node B shall immediately respond with UL SYNCHRONISATION control frame indicating the ToA for the DL SYNCHRONISATION control frame and the CFN indicated in the received message.
The procedure shall not be applied on transport bearers transporting UL traffic channels RACH [FDD and 1.28Mcps TDD – , E-DCH for CELL_FACH and Idle] or USCH.
In case a CRNC sends DL SYNCHRONISATION control frame to Node B via IP multicast transport bearer, the target CFN indicates the target MFN. Upon reception of the DL SYNCHRONISATION control frame Node B shall immediately respond with UL SYNCHRONISATION control frame via one unicast transport bearer indicating the ToA for the DL SYNCHRONISATION control frame and the MFN indicated in the received message.
In case a transport bearer without IP multicast option is used by several FACH channels, the procedure shall take place for all these FACH channels.
Figure 8: Transport Channels Synchronisation procedure
5.4 DL Timing Adjustment
Timing Adjustment procedure is used to indicate for the CRNC the incorrect arrival time of downlink data to Node B.
Timing Adjustment procedure is initiated by the Node B if a DL frame arrives outside of the defined arrival window.
If the DL frame has arrived before the ToAWS or after the ToAWE Node B includes the ToA and the target CFN as message parameters for TIMING ADJUSTMENT control frame.
In case a transport bearer without IP multicast option is used by several FACH channels, the procedure shall take place for all these FACH channels.
The arrival window and the time of arrival are defined as follows:
– Time of Arrival Window Endpoint (ToAWE): ToAWE represents the time point by which the DL data shall arrive to the Node B from Iub. The ToAWE is defined as the amount of milliseconds before the last time point from which a timely DL transmission for the identified CFN would still be possible taking into account the Node B internal delays. ToAWE is set via control plane. If data does not arrive before ToAWE a TIMING ADJUSTMENT control frame shall be sent by Node B.
– Time of Arrival Window Startpoint (ToAWS): ToAWS represents the time after which the DL data shall arrive to the Node B from Iub. The ToAWS is defined as the amount of milliseconds from the ToAWE. ToAWS is set via control plane. If data arrives before ToAWS a TIMING ADJUSTMENT control frame shall be sent by Node B.
– Time of Arrival (ToA): ToA is the time difference between the end point of the DL arrival window (ToAWE) and the actual arrival time of DL frame for a specific CFN. A positive ToA means that the frame is received before the ToAWE, a negative ToA means that the frame is received after the ToAWE.
The general overview on the timing adjustment procedure is reported in TS 25.402 [2].
Figure 9: Timing Adjustment procedure
5.5 Dynamic PUSCH Assignment [TDD]
Procedure for dynamic allocation of physical resources to uplink shared channels (USCH) in the Node B. The control frame includes a parameter "PUSCH Set Id" which is a pointer to a pre-configured table of PUSCH Sets in the Node B.
When this control frame is sent via a certain Iub USCH data port, then it applies to that USCH and in addition to any other USCH channel which is multiplexed into the same CCTrCH in the Node B.
The time limitation of the PUSCH allocation is expressed with the parameters "Activation CFN" and "Duration".
Node B behaviour: When the Node B receives the "DYNAMIC PUSCH ASSIGNMENT" from the CRNC in the USCH frame protocol over an Iub USCH data port within a Traffic Termination Point, it shall behave as follows:
1) The Node B shall extract the PUSCH Set Id.
2) It shall extract the parameters "Activation CFN" and "Duration" which identify the allocation period of that physical channel.
3) It shall retrieve the PUSCH Set which is referred to by the PUSCH Set Id.
4) It shall identify the CCTrCH to which the USCH is multiplexed, and hence the TFCS which is applicable for the USCH.
5) Within the time interval indicated by Activation CFN and Duration, the Node B shall make the specified PUSCH Set available to the CCTrCH.
Figure 10: Dynamic PUSCH Assignment procedure
5.6 DSCH TFCI Signalling [FDD]
Void.
5.7 Timing Advance [3.84 Mcps and 7.68Mcps TDD]
This procedure is used in order to signal to the Node B the adjustment to be performed by the UE in the uplink timing.
The Node B shall use the CFN and timing adjustment values to adjust its layer 1 to allow for accurate impulse averaging.
Figure 12: Timing Advance procedure
5.7A Outer Loop PC Information Transfer [1.28 Mcps TDD]
Based, for example, on the CRCI values and on the quality estimate in the USCH data frames, CRNC modifies the SIR target of the associated CCTrCH by including the absolute value of the new SIR target in the OUTER LOOP PC control frame sent to the Node B.
At the reception of the OUTER LOOP PC control frame from the CRNC via a Transport Bearer used for an USCH, the Node B shall immediately update the SIR target used for the inner loop power control for the respective CCTrCH with the specified value.
The OUTER LOOP PC control frame can be sent via any of the transport bearers carrying USCHs which belong to the CCTrCH for which the UL SIR Target shall be adjusted.
Figure 12A: Outer Loop Power Control Information Transfer procedure
5.8 General
5.8.1 Association between transport bearer and data/control frames
Table 1 shows how the data and control frames are associated to the transport bearers. ‘yes’ indicates that the control frame is applicable to the transport bearer, ‘no’ indicates that the control frame is not applicable to the transport bearer.
Table 1
|
Transport bearer used for |
Associated data frame |
Associated control frames |
||||||||||||||||||||
|
Timing Adjust-ment |
DL Transport Channels Synchronisation |
Node Synchronisation |
Dynamic PUSCH Assignment |
Timing Advance |
Outer Loop PC Info Transfer |
HS-DSCH Capacity Request |
HS-DSCH Capacity Allocation TYPE 1 |
HS-DSCH PDU Drop Indication |
||||||||||||||
|
RACH |
RACH DATA FRAME |
no |
no |
no |
no |
no |
no |
no |
no |
no |
||||||||||||
|
FACH |
FACH DATA FRAME |
yes |
yes |
yes1 |
no |
no |
no |
no |
no |
no |
||||||||||||
|
PCH |
PCH DATA FRAME |
yes |
yes |
yes |
no |
no |
no |
no |
no |
no |
||||||||||||
|
DSCH |
DSCH DATA FRAME |
yes |
yes |
yes |
no |
no |
no |
no |
no |
no |
||||||||||||
|
USCH |
USCH DATA FRAME |
no |
no |
no |
yes |
yes |
yes |
no |
no |
no |
||||||||||||
|
HS-DSCH |
HS-DSCH DATA FRAME TYPE 1 |
no |
no |
yes |
no |
no |
no |
yes |
yes |
yes |
||||||||||||
|
HS-DSCH |
HS-DSCH DATA FRAME TYPE 2 |
no |
no |
yes |
no |
no |
no |
yes |
no |
yes |
||||||||||||
|
HS-DSCH |
HS-DSCH DATA FRAME TYPE 3 |
yes |
yes |
yes |
no |
no |
no |
no |
no |
no |
||||||||||||
|
E-DCH for CELL FACH and Idle |
E-DCH DATA FRAME |
no |
no |
no |
no |
no |
no |
no |
no |
no |
||||||||||||
NOTE: 1: The associated control frame is not applicable to the transport bearer with IP multicast option.
5.8.2 DSCH / USCH transport bearer replacement [TDD]
As described in NBAP (TS 25.433 [6]), transport bearer replacement can be achieved for a DSCH or USCH by using the Synchronised Radio Link Reconfiguration Preparation procedure in combination with the Synchronised Radio Link Reconfiguration Commit procedure. The following steps can be discerned:
1) The new transport bearer is established after which 2 transport bearers exist in parallel.
2) The transport channel(s) is/are switched to the new transport bearer.
3) The old transport bearer is released.
DSCH transport bearer replacement, step 1:
Communication on the old transport bearer continues as normal. In addition, the Node B shall support DSCH DATA FRAMEs, the DL Transport Channel Synchronisation procedure (see sub-clause 5.3) and the DL Timing Adjustment procedure (see sub-clause 5.4) on the new bearer. This enables the CRNC to determine the timing on the new transport bearer. DSCH DATA FRAMEs transported on the new transport bearer shall not be transmitted on the Uu Interface before the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message.
USCH transport bearer replacement, step 1:
Communication on the old transport bearer continues as normal.
DSCH / USCH Transport Bearer Replacement step 2:
Regarding step 2), the moment of switching is determined as follows:
– The DSCH DATA FRAMEs or USCH DATA FRAMEs shall be transported on the new transport bearer from the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message.
Starting from this CFN the Node B shall support all applicable Common Transport Channels frame protocol procedures on the new transport bearer and no requirements exist regarding support of Common Transport Channels frame protocol procedures on the old transport bearer.
DSCH / USCH Transport Bearer Replacement step 3:
Finally in step 3), the old transport bearer is released.
5.8.3 HS-DSCH Transport Bearer Replacement
As described in NBAP (TS 25.433 [6]), transport bearer replacement can be achieved for a HS-DSCH MAC-d Flow by using the Synchronised Radio Link Reconfiguration Preparation procedure in combination with the Synchronised Radio Link Reconfiguration Commit procedure, or by using the Unsynchronised Radio Link Reconfiguration procedure. In both cases the following steps can be discerned:
1) The new transport bearer is established after which 2 transport bearers exist in parallel.
2) The HS-DSCH MAC-d Flow is switched to the new transport bearer.
3) The old transport bearer is released.
HS-DSCH Transport Bearer Replacement, step 1:
Communication on the old transport bearer continues as normal. In addition, the Node B shall support HS-DSCH DATA FRAMEs (TYPE 1 or TYPE 2), the HS-DSCH CAPACITY REQUEST Control Frame (see sub-clause 5.9) and may support the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame (see sub-clause 5.10) on the new transport bearer. HS-DSCH DATA FRAMEs (TYPE 1 or TYPE 2) transported on the new transport bearer shall be transmitted on the Uu Interface in the same way as those received on the old transport bearer (see sub-clause 5.1.6).
The Node B may use the old or the new transport bearer for the HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame. The HS-DSCH CAPACITY ALLOCATION (TYPE 1 or TYPE 2) Control Frame indicates the total amount of capacity granted for the MAC-d flow and the indicated priority level, irrespective of the transport bearer used. Any capacity previously granted is replaced.
The RNC may use the old or the new transport bearer for the HS-DSCH CAPACITY REQUEST Control Frame. The rules for reissuing a HS-DSCH CAPACITY REQUEST Control Frame as outlined in sub-clause 5.9 still apply.
HS-DSCH Transport Bearer Replacement, step 2:
Regarding step 2), the moment of switching is determined as follows:
Starting from the CFN indicated in the RADIO LINK RECONFIGURATION COMMIT message – or directly when using the unsynchronised Radio Link Reconfiguration procedure, the Node B shall support all applicable Common Transport Channels frame protocol procedures on the new transport bearer and no requirements exist regarding support of Common Transport Channels frame protocol procedures on the old transport bearer.
HS-DSCH Transport Bearer Replacement, step 3:
Finally in step 3), the old transport bearer is released.
5.9 HS-DSCH Capacity Request
Figure 12B: HS-DSCH Capacity Request procedure
The HS-DSCH Capacity Request procedure provides means for the CRNC to request HS-DSCH capacity by indicating the user buffer size in the CRNC for a given priority level.
The CRNC is allowed to reissue the HS-DSCH Capacity Request if no CAPACITY ALLOCATION (TYPE 1 or TYPE 2) has been received within an appropriate time threshold.
5.10 HS-DSCH Capacity Allocation
Figure 12C: HS-DSCH Capacity Allocation procedure
HS-DSCH Capacity Allocation procedure is generated within the Node B. It may be generated either in response to a HS-DSCH Capacity Request or at any other time.
The Node B may use this message to modify the capacity at any time, irrespective of the reported user buffer status.
The HS-DSCH CAPACITY ALLOCATION (TYPE 1 and TYPE 2) Control Frame is used by the Node B to control the user data flow. In case of HS-DSCH Frame Protocol TYPE 1, the HS-DSCH Credits IE indicates the number of MAC-d PDUs that the CRNC is allowed to transmit for the MAC-d flow and the associated priority level indicated by the Common Transport Channel Priority Indicator IE. In case of HS-DSCH Frame Protocol TYPE 2, the HS-DSCH Credits IE multiplied by the Maximum MAC – d/c PDU Length IE indicates the number of MAC-d PDU [FDD and 1.28Mcps TDD – or MAC-c PDU] octets that the CRNC is allowed to transmit for the MAC-d flow [FDD and 1.28Mcps TDD – or Common MAC flow] and the associated priority level indicated by the Common Transport Channel Priority Indicator IE.
The Maximum MAC-d PDU Length (in case of HS-DSCH Frame Protocol TYPE 1) or Maximum MAC- d/c PDU Length (in case of HS-DSCH Frame Protocol TYPE 2), HS-DSCH Credits, HS-DSCH Interval and HS-DSCH Repetition Period IEs indicates the total amount of capacity granted. Any capacity previously granted is replaced.
If HS-DSCH Credits IE = 0 (e.g. due to congestion in the Node B), the CRNC shall immediately stop transmission of MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs]. If HS-DSCH Credits IE = 2047 in case of HS-DSCH CAPACITY ALLOCATION TYPE 1 Control Frame or 65535 in case of HS-DSCH CAPACITY ALLOCATION TYPE 2 Control Frame, the CRNC can transmit MAC-d PDUs [FDD and 1.28Mcps TDD – or MAC-c PDUs] with unlimited capacity.
The IEs used in the HS-DSCH CAPACITY ALLOCATION Control Frame (TYPE 1 and TYPE 2) are the Common Transport Channel Priority Indicator, HS-DSCH Credits, Maximum MAC- d PDU Length (in case of HS-DSCH Frame Protocol TYPE 1) or Maximum MAC- d/c PDU Length (in case of HS-DSCH Frame Protocol TYPE 2), HS-DSCH Interval and the HS-DSCH Repetition Period.
If the HS-DSCH Repetition Period IE = "unlimited repetition period" it indicates that the CRNC may transmit the amount of granted capacity for an unlimited period according to the bounds of Maximum MAC-d PDU Length IE (TYPE 1) or Maximum MAC- d/c PDU length IE (TYPE 2), HS-DSCH Credits IE and HS-DSCH Interval IE.
5.11 Indication of UE State Transition [1.28Mcps TDD]
In 1.28Mcps TDD, for UE in CELL_PCH state with dedicated H-RNTI, the network will inform the UE to establish the uplink synchronization via HS-SCCH before transmitting DCCH and DTCH to the UE. And when UE receives dedicated H-RNTI on HS-SCCH, the UE shall initiate the uplink synchronization procedure and transit to CELL_FACH state. After the Node B received the confirmation from UE (upon detection of the UE’s E-RUCCH), it shall send the UE State Transition Indication to RNC through E-DCH user data frame with dedicated E-RNTI to inform that the UE’s state has been transited from CELL_PCH to CELL_FACH.
The UE State Transition Indication is indicated in E-DCH user data frame with values set as follows:
– The CFN and Subframe Number IE values shall reflect the time when the state transition was detected
– The Number of MAC-is SDUs IE shall be set to zero. As a consequence there are no MAC-is PDU descriptor IE and there are no MAC-is PDUs IEs in the payload part of the data frame related to UE state transition indication.
5.12 HS-DSCH UL Synchronization Establishment Failure [1.28Mcps TDD]
Figure 12D: HS-DSCH UL Synchronization Establishment Failure procedure
In 1.28Mcps TDD, when the Node B needs to transmit HS-DSCH data to the UE in CELL_FACH state, the Node B will inform the UE to establish the uplink synchronization via HS-SCCH before HS-DSCH data transmission (TS 25.224 [14]). During this uplink sychronization establishment procedure, if the uplink synchronization failure indication from lower layer is received (TS 25.224 [14]), the Node B could use the HS-DSCH UL SYNCHRONIZATION ESTABLISHMENT FAILURE control frame to notify the RNC to terminate the HS-DSCH data transmission. The H-RNTI IE contains the same value as the H-RNTI currently allocated to the UE.
5.13 HS-DSCH PDU DROP INDICATION
Figure 12E: HS-DSCH PDU DROP INDICATION procedure
The HS-DSCH PDU DROP INDICATION Control Frame is used by the Node B to report to CRNC the PDU drop events. It is used when Node B drops the PDUs. The content of the dropped PDU or Data Frame is available in the Node B so in this case direct identification of the PDUs is possible.