7.3.8 Details of MAC-i

25.3193GPPEnhanced uplinkOverall descriptionStage 2TS

In CELL_DCH state, there is one MAC-i entity in the NodeB for each UE.

For FDD, in CELL_FACH state and Idle mode, there is a collision resolution phase at the beginning of the data transmission over the assigned common E-DCH resource where one or more UEs may access the MAC-i entity in the Node B. After this phase the MAC-i entity in the Node B will be accessed at most by one UE.

For 1.28Mcps TDD, in CELL_FACH state and Idle mode, there is a common E-RNTI collision resolution phase at the beginning of enhanced random access where one or more UEs may access the MAC-i entity in the Node B using a same common E-RNTI. After this phase the MAC-i entity in the Node B will be accessed at most by one UE.

There is one E-DCH scheduler function in the Node-B. The MAC-i and E-DCH scheduler handle Enhanced Uplink specific functions in the NodeB. In the model below, the MAC-i and E-DCH scheduler comprises the following entities:

– E-DCH Scheduling:
This function manages E-DCH cell resources between UEs. Based on scheduling requests, Scheduling Grants are determined and transmitted. The general principles of the E-DCH scheduling are described in subclause 9.1 below. However implementation is not specified (i.e. depends on RRM strategy).

– E-DCH Control:
The E-DCH control entity is responsible for reception of scheduling requests and transmission of Scheduling Grants. For FDD, for UEs in CELL_FACH state, the E-DCH control entity is additionally responsible for collision resolution and common E-DCH resource release by transmitting Scheduling Grants. For 1.28Mcps TDD, for UEs in CELL_FACH state, the E-DCH control entity is additionally responsible for common E-RNTI collision resolution by transmitting Scheduling Grants.
The general principles of the E-DCH scheduling are described in subclause 9.1 below.

– De-multiplexing:
This function provides de-multiplexing of MAC-i PDUs. For DCCH and DTCH transmission, MAC-is PDUs are forwarded to the associated MAC-d flow. For CCCH transmission, MAC-is PDUs are forwarded to the associated UL Common MAC Flow. For Dual Cell E-DCH operation, there is one De-multiplexing entity per E-DCH transport channel. For 1.28 Mcps TDD Multi-Carrier E-DCH operation, there is only one De-multiplexing entity for all E-DCH transport channels per UE.

– Read UE ID (FDD only):
In CELL_DCH state, no UE ID is included in the MAC-PDU header.
In CELL_FACH, if an E-RNTI is allocated to the UE, then the E-RNTI is added in all MAC-i PDUs at the UE side until the UE receives an E-AGCH with its E-RNTI (through an E-RNTI-specific CRC attachment). When the UE’s E-RNTI is present, it identifies DCCH and DTCH data transmission from this UE.
In CELL_FACH state if no E-RNTI is allocated and in Idle mode, the only CCCH data can be transmitted only as no E-RNTI has been added in the MAC-i PDU for transmission from the UE.

– HARQ:
One HARQ entity is capable of supporting multiple instances (HARQ processes) of stop and wait HARQ protocols. Each process is responsible for generating ACKs or NACKs indicating delivery status of E-DCH transmissions. The HARQ entity handles all tasks that are required for the HARQ protocol. For Dual Cell E-DCH operation, there is one HARQ entity per E-DCH transport channel. For 1.28 Mcps TDD Multi-Carrier E-DCH operation, there is one HARQ sub-entity per E-DCH transport channel.

The associated signalling shown in the figure illustrates the exchange of information between layer 1 and layer 2 provided by primitives.

Figure 7.3.8-1: UTRAN side MAC architecture / MAC-i details (FDD only)

Figure 7.3.8-2: UTRAN side MAC architecture / MAC-i details (TDD only)

Figure 7.3.8-2a: UTRAN side MAC architecture / MAC-i details (1.28 Mcps TDD Multi-Carrier E-DCH operation)