HSDPA is a concept that was introduced for UTRAN architectures as an enhancement to the shared channel concept in 3GPP (3rd generation partnership project).
In UMTS, the UTRAN handles all radio-related functionality. To this end, a UTRAN comprises one or more RNCs, and connected to each RNC one or more Node Bs. The RNCs of the UTRAN are connected to a core network via an Iur interface. RNCs of one UTRAN may be interconnected in addition by an Iur interface. In downlink transmissions, an RNC receives user data from the core network, possibly via another RNC, and forwards it via an Iub interface to a Node B. The Node B then transmits the data to the addressed user equipment UE via a Uu interface.
The RNCs of a UTRAN might take different roles. A controlling RNC (CRNC) may be defined, for example, with respect to a specific set of Node Bs. There is only one CRNC for any Node B. The CRNC has an overall control over the logical resources of its Node Bs. A serving RNC (SRNC) may be defined with respect to a specific connection between an UE and a UTRAN. There is one SRNC for each UE that has a connection to UTRAN. The SRNC is in charge of the radio resource control (RRC) connection between a UE and the UTRAN. The Serving RNC also terminates the Iu for this UE.
In the shared channel concept in UTRAN for FDD mode, a DSCH (downlink shared channel) is defined as a downlink transport channel which is shared dynamically between several UEs. The DSCH is assembled in a CRNC and transmitted via a Node B to a UE, as described for instance in the technical specification 3GPP TS 25.301 V3.6.0 (2000-09): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Radio Interface Protocol Architecture (Release 1999)”.
The basic idea of HSDPA is to offer for downlink transmissions shared high speed channels with a higher data rate and a quicker retransmission mechanism already from Node B. The shared high speed channels are to comprise a HS-DSCH (high speed downlink shared channel) as transport channel and a DPCH (dedicated physical channel), combined with a separate shared physical control channel in combination with a HS-PDSCH (high speed physical downlink shared channel). The fast retransmission mechanism to be implemented in the Node B is HARQ (hybrid automatic repeat request).
The currently used DSCH may also support high data rates, but retransmission is always provided by a RLC (radio link control) layer in the RNC, which slows the transaction down.
In order to support the new capabilities, especially HARQ, a new MAC (medium access control) entity was introduced in the technical report 3GPP TR 25.855 V1.0.0 (2001-06): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; High Speed Downlink Packet Access; Overall UTRAN Description (Release 5)”, which is incorporated by reference herein. The new MAC entity is called MAC −hs and is always located in the Node B. In the preceding releases of 3GPP, all UTRAN MAC entities capable of also handling user plane data were always located exclusively in the RNCs. The MAC −hs exists only when the cell is configured to support the HSDPA concept, and it is connected to a MAC −c/sh located in an RNC through the Iub interface.
A MAC layer is used for mapping logical channels to transport channels. A logical channel is a channel type which is defined between the radio link control (RLC) in an RNC and the MAC layer. Each logical channel defines what kind of data is going to be transmitted through it. In the case of HSDPA, the logical channels always locate in the SRNC. A transport channel is a channel type which is defined between the MAC layer and L1 (layer 1). It describes how data is to be transmitted through the radio link. In the DSCH concept, the transport channel is seen on the Iub interface, whereas in the HSDPA concept the transport channel is an internal channel in Node B.
The connection of different MACs of a UTRAN for HSDPA is illustrated in FIG. 1, which was taken from the above cited technical report TR 25.855.
FIG. 1 depicts a MAC −hs 1 located in a Node B, and in addition a MAC −c/sh 2 and a MAC −d 3 located in one or more RNCs. The MAC −hs 1 is connected to the MAC −c/sh 2 via the Iub interface, while the MAC −c/sh 2 is connected to the MAC −d 3 via an Iur interface in case they are located in different RNC, otherwise these MACs 2, 3 are interconnected locally. A MAC control has access to each of the MACs 1-3. Such logical channels as PCCH (Paging channel)and BCCH (broadcast control channel) are directly mapped to the MAC −c/sh 2 without intervening of MAC −d 3. However such logical channels as DCCH (Dedicated control channel) and DTCH (dedicated traffic channel) are always connected to MAC −d 3, which forwards the received data packets to the MAC −c/sh 2, if the UE has access rights either to the common channel(s) or to the shared channel(s). MAC −c/sh 2 and MAC −d 3 map different kinds of logical channels onto transport channels, like PCH (paging channel), FACH (forward access channel), DCH (dedicated channel) etc., for transmission to a UE via a Node B. Received HSDPA related data is provided by MAC −d 3 via MAC −c/sh 2 without mapping to the MAC −hs 1 of the Node B for transmission in HS DSCHs to a UE. For the details of FIG. 1 it is referred to the technical report TR 25.855.
Alternatively, the MAC −hs could be connected directly to a MAC −d.
Since functionalities previously implemented only in the RNCs have now to be provided also in Node Bs, like TFC (transport format combination) selection, the functional split between Node B and RNC has been reorganized. The new distribution of functionalities is shown in FIGS. 2 and 3, which were equally taken from technical report TR 25.855, and which presents in more detail some of the functions provided by MAC −c/sh 2 and MAC −hs 1 respectively.
Upon the reorganization, scheduling/priority handling and TFC selection functions have been removed from the MAC −c/sh 2 of the RNC in FIG. 2 for HSDPA related downlink transmissions and added to the MAC −hs 1 of the Node B in FIG. 3. Thus, the final scheduling and the real time traffic control is not under RNC control any more for HSDPA. Accordingly, in the MAC −c/sh 2 in FIG. 2, HSDPA related data received from a MAC −d are passed on to the MAC −hs 1 of FIG. 3 without any scheduling, priority handling or TFC selection etc. being performed as for other downlink data. Previously, these functions were always taken care of either in a SRNC when Node B was connected directly to an SRNC, or in a CRNC when the Node B was connected to an CRNC. In addition, HARQ is implemented in the new MAC −hs 1 of FIG. 3. For the details of FIGS. 2 and 3 it is referred to the above cited technical report TR 25.855.
The reorganization of functionalities implies that the known transmissions of downlink user data and of required control information from an RNC to a Node B has to be adapted.
For the transmission of downlink user data, it was proposed that the RLC layer is not changed. This means that the RLC buffers as before RLC PDUs (protocol data units) in RNC buffers, and that the RLC submits data to the lower layer only upon request of the MAC layer which locates on the RNC, i.e. MAC −d 3. Therefore the transactions to support data transmission between a MAC entity in an RNC and a MAC −hs 1 in a Node B are currently defined only on high level, but details are still missing. By these high level definitions, a flow control functionality is defined between MAC −c/sh 2 and MAC −hs 1 as a new feature, as indicated in FIG. 3, in order to control the data flow from the RNC to the Node B.
To support actual data transmissions on the Iub-interface, moreover a HS-DSCH Frame protocol layer (HS-DSCH FP) was included under the MAC −c/sh and above the MAC −hs. This layer is indicated in FIG. 4, which was again taken from technical report TR 25.855. FIG. 4 shows a radio interface protocol architecture of HSDPA, and more specifically layers of network elements which network elements are, from left to right, a user equipment UE connected via a Uu interface to a Node B, which is further connected via an Iub interface to a first RNC, which is finally connected via an Iur interface to a second RNC. Each of the Node B, the first and the second RNC comprises in addition to the respective MAC entity a HS-DSCH FP. This HS-DSCH FP is intended to transmit not only data packets from the RNC to the Node B, but also related control information. Such an FP protocol is proposed without any details for data transmissions in downlink on both, Iub and Iur interfaces, which transmissions are using the service of L2 (layer 2) of MAC and RLC. For the details of FIG. 4, it is referred to the above cited technical report TR 25.855.
None of the current FP frame structures defined for the Iub interface, however, is applicable for HSDPA. In particular the FP frame structure used for DSCHs, from which DSCHs the proposal for HSDPA proceeds, is not suited for HSDPA data transmissions, since a DSCH FP frame contains fields of which the values can only be defined when the scheduling or TFC selection has already been made. As mentioned above, these functions were shifted for HSDPA related transmissions to the Node B. Moreover, a DSCH FP frame does not contain all of the information which is required for HSDPA to support flow control between an RNC and a Node B.
In addition to HSDPA related user data, also control information has to be available at the Node B so that the Node B can set up and re-configure HS-DSCH channels for transmissions.
Due to the functional reorganization, the current application protocol procedures on Iub for DSCH setup and reconfiguration, described e.g. in the technical specification 3GPP TS 25.433 V3.4.1 (2000-12): “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iub Interface NBAP Signalling (Release 1999)”, cannot be used for HS-DSCH. For example, in the case of HSDPA it is not necessary to provide channel coding parameters during a radio link (RL) setup as for DSCH, since these channel coding parameters are decided upon in the Node B. On the other hand, some parameters that are not required by a Node B for DSCH should be provided to a Node B for HSDPA during a cell setup procedure so the Node B can configure HS-DSCH attributes in a cell. It should moreover be possible to modify these parameters cell-based, preferably in a semi-static manner.