4.2.4 Traffic Related Architecture – UTRAN Side

25.3213GPPMedium Access Control (MAC) protocol specificationTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

Figure 4.2.4-1 illustrates the connectivity between the MAC entities from the UTRAN side.

It is similar to the UE case with the exception that there will be one MAC-d for each UE and each UE (MAC-d) that is associated with a particular cell may be associated with that cell’s MAC-c/sh/m.

MAC-c/sh/m is located in the controlling RNC while MAC-d is located in the serving RNC. MAC-hs/ehs is located in the Node B. The MAC-d PDUs to be transmitted are transferred from MAC-c/sh/m to the MAC-hs/ehs via the Iub interface in case of configuration with MAC-c/sh/m, or from the MAC-d via Iur/Iub in case of configuration without MAC-c/sh/m.

For TDD, and for FDD in CELL_DCH, for each UE that uses E-DCH, one MAC-e or MAC-i entity per Node-B and one MAC-es or MAC-is entity in the SRNC are configured. MAC-e or MAC-i, located in the Node B, controls access to the E-DCH and is connected to MAC-es or MAC-is, located in the SRNC. MAC-es or MAC-is is further connected to MAC-d. There is one transport bearer set up per E-DCH MAC-d flow.

For FDD and 1.28 Mcps TDD, for DTCH and DCCH transmission in CELL_FACH, for each UE that uses E-DCH, one MAC-i entity per Node-B and one MAC-is entity in the SRNC are configured. MAC-i, located in the Node B, controls access to the E-DCH and is connected to MAC-is, located in the SRNC. MAC-is is further connected to MAC-d.

For FDD, for CCCH transmission, for each UE that uses E-DCH, one MAC-i entity per Node-B and one MAC-is entity in the CRNC are configured. MAC-i, located in the Node B, controls access to the E-DCH and is connected to MAC-is in the CRNC.

For 1.28 Mcps TDD, for CCCH transmission, for each UE that uses E-DCH, one MAC-i entity per common E-RNTI in Node-B and one MAC-is entity in the CRNC are configured. MAC-i, located in the Node B, controls access to the E-DCH and is connected to MAC-is in the CRNC.

The MAC Control SAP is used to transfer Control information to each MAC entity belonging to one UE.

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

Figure 4.2.4-1: UTRAN side MAC architecture

4.2.4.1 MAC-c/sh/m entity – UTRAN Side

Figure 4.2.4.1-1 shows the UTRAN side MAC-c/sh/m entity. The following functionality is covered:

– Scheduling – Buffering – Priority Handling;

– this function manages FACH and for TDD DSCH resources between the UEs and between data flows according to their priority and delay requirements set by higher layers.

– TCTF MUX

– this function represents the handling (insertion for downlink channels and detection and deletion for uplink channels) of the TCTF field in the MAC header, and the respective mapping between logical and transport channels.
The TCTF field indicates the common logical channel type, or if a dedicated logical channel is used;

– UE Id Mux;

– for dedicated type logical channels, the UE Id field in the MAC header is used to distinguish between UEs;

– MBMS Id Mux;

– for MTCH channels, the MBMS Id field in the MAC header is used to distinguish between MBMS services;

– TFC selection:

– in the downlink, transport format combination selection is done for FACH and PCH and for TDD DSCHs;

– Demultiplex;

– for TDD operation the demultiplex function is used to separate USCH data from different UEs, i.e. to be transferred to different MAC-d entities;

– DL code allocation;

– for TDD this function is used to indicate the code used on the DSCH;

– Flow control;

– a flow control function exists toward MAC-d to limit buffering between MAC-d and MAC-c/sh/m entities. a flow control function also exists towards MAC-hs/ehs in case of configuration with MAC-c/sh/m.

The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels.

There is one MAC-c/sh/m entity in the UTRAN for each cell;

Figure 4.2.4.1-1: UTRAN side MAC architecture / MAC-c/sh/m details

4.2.4.2 MAC-d entity – UTRAN Side

Figure 4.2.4.2-1 shows the UTRAN side MAC-d entity.

The following functionality is covered:

– Transport Channel type switching:

– Transport Channel type switching is performed by this entity, based on decision taken by RRC; this is related to a change of radio resources. If requested by RRC, MAC shall switch the mapping of one designated logical channel between common and dedicated transport channels.

– C/T MUX box;

– the function includes the C/T field when multiplexing of several dedicated logical channels onto one transport channel (other than HS-DSCH) or one MAC-d flow (HS-DSCH) is used. If MAC-ehs is configured, C/T MUX toward MAC-ehs is not used.

– LCH MUX box;

– If MAC-ehs is configured, the LCH MUX function associates each block of MAC-d PDUs of a logical channel with the related LCH-ID, regardless whether one or several logical channels are multiplexed onto one MAC-d flow.

– Priority setting;

– This function is responsible for priority setting on data received from DCCH / DTCH;

– Ciphering;

– Ciphering for transparent mode data to be ciphered is performed in MAC-d. Details about ciphering can be found in [10].

– Deciphering;

– Deciphering for ciphered transparent mode data is performed in MAC-d. Details about ciphering can be found in [10].

– DL Scheduling/Priority handling;

– in the downlink, scheduling and priority handling of transport channels is performed within the allowed transport format combinations of the TFCS assigned by the RRC.

– Flow Control;

– a flow control function exists toward MAC-c/sh/m to limit buffering between MAC-d and MAC-c/sh/m entities. This function is intended to limit layer 2 signalling latency and reduce discarded and retransmitted data as a result of FACH or for TDD DSCH congestion. For the Iur interface this is specified in [11]. A flow control function also exists towards MAC-hs/ehs in case of configuration without MAC-c/sh/m, see subclause 4.2.4.2.

A MAC-d entity using common channels other than the high speed downlink shared channel is connected to a MAC-c/sh/m entity that handles the scheduling of the common channels to which the UE is assigned and DL (FACH) priority identification to MAC-c/sh/m;

A MAC-d entity using downlink shared channel is connected to a MAC-c/sh/m entity that handles the shared channels to which the UE is assigned and indicates the level of priority of each PDU to MAC-c/sh/m;

A MAC-d entity using the high speed downlink shared channel may be connected to a MAC-c/sh/m entity that in turn is connected to the MAC-hs/ehs entity in the Node B (configuration with MAC-c/sh/m); alternately, a MAC-d entity using the high speed downlink shared channel may be connected to the MAC-hs/ehs entity in the Node B in case of configuration without MAC-c/sh/m.

A MAC-d entity using the enhanced dedicated transport channel (Uplink only) is connected to a MAC-es or MAC-is entity that handles the re-ordering and combining of data received from different Node Bs. Given that the MAC-es or MAC-is is collocated in the SRNC, it is not necessary to flow control this connection. The MAC-es or MAC-is indicates the logical channel for which the data is intended, to allow the MAC-d to route it appropriately.

A MAC-d entity is responsible for mapping dedicated logical channels onto the available dedicated transport channels or routing the data received on a DCCH or DTCH to MAC-c/sh/m or to MAC-hs/ehs.

One dedicated logical channel can be mapped simultaneously on DCH and DSCH in TDD mode. Different scheduling mechanisms apply for DCH and DSCH. One dedicated logical channel can be mapped simultaneously on DCH and HS-DSCH.

There is one MAC-d entity in the UTRAN for each UE that has one or more dedicated logical channels to or from the UTRAN.

Figure 4.2.4.2-1: UTRAN side MAC architecture / MAC-d details

4.2.4.3 MAC-hs entity – UTRAN Side

There is one MAC-hs entity in the UTRAN for each cell that supports HS-DSCH transmission. The MAC-hs is responsible for handling the data transmitted on the HS-DSCH when configured by upper layers. Furthermore, when configured by upper layers, it is responsible for the management of the physical resources allocated to HSDPA. There should be priority handling per MAC-d PDU in the MAC-hs. The MAC-hs is comprised of four different functional entities:

– Flow Control:
This is the companion flow control function to the flow control function in the MAC-c/sh/m in case of configuration with MAC-c/sh/m and MAC-d in case of configuration without MAC-c/sh/m. Both entities together provide a controlled data flow between the MAC-c/sh/m and the MAC-hs (Configuration with MAC-c/sh/m) or the MAC-d and MAC-hs (Configuration without MAC-c/sh/m) taking the transmission capabilities of the air interface into account in a dynamic manner. This function is intended to limit layer 2 signalling latency and reduce discarded and retransmitted data as a result of HS-DSCH congestion. Flow control is provided independently by MAC-d flow for a given MAC-hs entity.

– Scheduling/Priority Handling:
This function manages HS-DSCH resources between HARQ entities and data flows according to their priority. Based on status reports from associated uplink signalling either new transmission or retransmission is determined. Further it determines the Queue ID and TSN for each new MAC-hs PDU being serviced, and in the case of TDD the HCSN is determined. A new transmission can be initiated instead of a pending retransmission at any time to support the priority handling.

In 1.28 Mcps TDD multi-frequency HS-DSCH cell:

– multiple HARQ processes are assigned for HS-DSCH operaton on every carrier for every user, namely HARQ sub-entity; only one HARQ process in HARQ sub-entity is allowed to receive HS-DSCH in one TTI for each carrier.

– choice of 6bit or 9bit TSN is configured by upper layer signalling

– HARQ:
One HARQ entity handles the hybrid ARQ functionality for one user. One HARQ entity is capable of supporting multiple instances (HARQ process) of stop and wait HARQ protocols. There shall be one HARQ process per HS-DSCH per TTI. In 1.28 Mcps TDD multi-frequency HS-DSCH cell, multiple HARQ processes are assigned independently for HS-DSCH operation on every carrier for every user, namely HARQ sub-entity. Only one HARQ process in HARQ sub-entity is allowed to receive HS-DSCH in one TTI for each carrier.

– TFRC selection:
Selection of an appropriate transport format and resource for the data to be transmitted on HS-DSCH.

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

Figure 4.2.4.3-1: UTRAN side MAC architecture / MAC-hs details

Figure 4.2.4.3-2: UTRAN side MAC architecture/MAC-hs details (1.28Mcps TDD multi-frequency HS-DSCH operation mode only)

4.2.4.4 MAC-es entity – UTRAN Side

For each UE, there is one MAC-es entity in the SRNC. When configured by the upper layers, the MAC-es sublayer handles E-DCH specific functionality, which is not covered in the MAC-e entity in Node B. In the model below, the MAC-es comprises the following entities:

– Reordering Queue Distribution:
The reordering queue distribution function routes the MAC-es PDUs to the correct reordering buffer based on the SRNC configuration.

– Reordering:
This function reorders received MAC-es PDUs according to the received TSN and Node-B tagging i.e. (CFN, subframe number). MAC-es PDUs with consecutive TSNs are delivered to the disassembly function upon reception. Mechanisms for reordering MAC-es PDUs received out-of-order are left up to the implementation. There is one Re-ordering Process per logical channel.

– Macro diversity selection (FDD only):
The function is performed in the MAC-es, in case of soft handover with multiple Node-Bs (The soft combining for all the cells of a Node-B takes place in the Node-B). This means that the reordering function receives MAC-es PDUs from each Node-B in the E-DCH active set. The exact implementation is not specified. However the model below is based on one Reordering Queue Distribution entity receiving all the MAC-d flow from all the Node-Bs, and one MAC-es entity per UE.

– Disassembly:
The disassembly function is responsible for disassembly of MAC-es PDUs. When a MAC-es PDU is disassembled the MAC-es header is removed, the MAC-d PDU’s are extracted and delivered to MAC-d.

Figure 4.2.4.4-1: UTRAN side MAC architecture / MAC-es details (SHO case, FDD only)

Figure 4.2.4.4-1b: UTRAN side MAC architecture / MAC-es details (TDD)

4.2.4.5 MAC-e entity – UTRAN Side

There is one MAC-e entity in the Node B for each UE and one E-DCH scheduler function in the Node-B. When configured by the upper layers the MAC-e and E-DCH scheduler handle HSUPA specific functions in the Node B. In the model below, the MAC-e 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 subclauses 11.8.2.3 and 11.9.2.3 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. The general principles of the E-DCH schedulling are described in subclauses 11.8.2.3 and 11.9.2.3 below.

– De-multiplexing:
This function provides de-multiplexing of MAC-e PDUs. MAC-es PDUs are forwarded to the associated MAC-d flow.

– 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.

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

Figure 4.2.4.5-1a: UTRAN side MAC architecture / MAC-e details (FDD)

Figure 4.2.4.5-1b: UTRAN side MAC architecture / MAC-e details (TDD)

4.2.4.6 MAC-ehs entity UTRAN Side

There is one MAC-ehs entity in the UTRAN for each cell that supports HS-DSCH transmission. The same MAC-ehs entity may support HS-DSCH transmission in more than one cell served by the same Node-B (FDD only). The MAC-ehs is responsible for handling the data transmitted on the HS-DSCH when configured. There should be priority handling per MAC-ehs SDU in the MAC-ehs. The MAC-ehs is comprised of six different functional entities:

– Flow Control:
The flow control for MAC-ehs is identical to the flow control for MAC-hs.

– Scheduling/Priority Handling:
This function manages HS-DSCH resources between HARQ entities and data flows according to their priority class. In FDD and 1.28Mcps TDD, the scheduler determines for each TTI if single or dual stream transmission should be used. Based on status reports from associated uplink signalling either new transmission or retransmission is determined when operating in CELL_DCH state. In FDD, when operating in CELL_FACH, CELL_PCH and URA_PCH state HS-DSCH reception, the MAC-ehs can perform retransmission without uplink signalling. In 1.28 Mcps TDD, when operating in CELL_FACH, CELL_PCH and URA_PCH state and HS-DSCH reception without dedicated H-RNTI, the MAC-ehs can perform retransmission without uplink signalling. Further it sets the logical channel identifiers for each new reordering SDU and TSNs for each new reordering PDU being serviced. To maintain proper transmission priority a new transmission can be initiated on a HARQ process at any time. The TSN is unique to each MAC-ehs Queue ID within a HS-DSCH. It is not permitted to schedule new transmissions, including retransmissions originating in the RLC layer, along with retransmissions originating from the HARQ layer within the same TTI over the same HS-DSCH, and HARQ process (FDD only). It is not permitted to schedule new transmissions, including retransmissions originating in the RLC layer, along with retransmissions originating from the HARQ layer within the same TTI, and HARQ process (TDD only).

– HARQ:
One HARQ entity handles the hybrid ARQ functionality for one user and per HS-DSCH transport channel (FDD only). One HARQ entity handles the hybrid ARQ functionality for one user (TDD only). One HARQ entity is capable of supporting multiple instances (HARQ process) of stop and wait HARQ protocols. There shall be one HARQ entity per HS-DSCH, one HARQ process per HS-DSCH per TTI for single stream transmission, two HARQ processes per HS-DSCH per TTI for dual stream transmission (FDD only), three HARQ processes per HS-DSCH per TTI for three stream transmission (FDD only)and four HARQ processes per HS-DSCH per TTI for four stream transmission (FDD only). There shall be one HARQ process per TTI for single stream transmission and two HARQ processes per TTI for dual stream transmission (TDD only).

In 1.28 Mcps TDD multi-frequency HS-DSCH cell:

– choice of 6bit or 9bit TSN is configured by upper layer signalling.

– TFRC selection:
The TFRC selection for MAC-ehs is identical to the TFRC selection of the MAC-hs. In case of three stream transmission, the MAC-ehs PDU belonging to the second stream and the MAC-ehs PDU belonging to the third stream should be of equal size. In case of four stream transmission, the MAC-ehs PDU belonging to the first stream and the MAC-ehs PDU belonging to the fourth stream should be of equal size, the MAC-ehs PDU belonging to the second stream and the MAC-ehs PDU belonging to the third stream should be of equal size.

– Priority Queue MUX:
This function determinates the number of octets to be included in a MAC-ehs PDU from each priority queue based on the scheduling decision and available TFRC for this function.

– Segmentation:
This function performs necessary segmentation of MAC-ehs SDUs.

The following is allowed:

– The MAC-ehs SDUs included in a MAC-ehs PDU can have a different size and a different priority and can be mapped to different logical channels.

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

Figure 4.2.4.6-1: UTRAN side MAC architecture / MAC-ehs details

Figure 4.2.4.6-2: UTRAN side MAC architecture/MAC-ehs details (1.28Mcps TDD multi-frequency HS-DSCH operation mode only)

4.2.4.7 MAC-is entity – UTRAN Side

For TDD, and for FDD in CELL_DCH and CELL_FACH, for each UE, there is one MAC-is entity in the SRNC. For FDD, for CCCH transmission in CELL_FACH state and Idle mode, there is one MAC-is entity per common E-DCH resource configured in the controlling RNC. For 1.28 Mcps TDD, for CCCH transmission in CELL_FACH state and Idle mode, there is one MAC-is entity per UE in the controlling RNC. When configured by the upper layers. the MAC-is sublayer handles E-DCH specific functionality, which is not covered in the MAC-i entity in Node B. In the model below, the MAC-is comprises the following entities:

– Disassembly:

The disassembly function is responsible for disassembly of MAC-is PDUs. When a MAC-is PDU is disassembled the MAC-is header is removed.

– Reordering Queue Distribution:

For DCCH and DTCH transmission, the reordering queue distribution function routes the MAC-is PDUs to the correct reordering buffer based on the SRNC configuration.

– Reordering:

This function reorders received MAC-is PDUs according to the received TSN and Node-B tagging i.e. (CFN, subframe number). MAC-is PDUs with consecutive TSNs are delivered to the disassembly function upon reception. Mechanisms for reordering MAC-is PDUs received out-of-order are left up to the implementation. There is one Re-ordering Process per logical channel.

– Macro diversity selection (FDD only):

The function is performed in the MAC-is, in case of soft handover with multiple Node-Bs (The soft combining for all the cells of a Node-B takes place in the Node-B). This means that the reordering function receives MAC-is PDUs from each Node-B in the E-DCH active set and in the Secondary E-DCH Active Set. The exact implementation is not specified. However the model below is based on one Reordering Queue Distribution entity receiving all the MAC-d flow from all the Node-Bs, and one MAC-is entity per UE.

– Reassembly:

For DTCH/DCCH transmission, the reassembly function reassembles segmented MAC-d PDUs, and delivers the MAC-d PDUs to the correct MAC-d entity. For CCCH transmission, the reassembly function reassembles segmented MAC-c PDUs, and delivers it to the CRC Error Detection function.

– CRC Error Detection (FDD and 1.28 Mcps TDD only):
When the MAC-c PDU is received correctly after reassembly is performed for CCCH, then the CRC field is removed and the resulting data is delivered to the MAC-c. However, if a MAC-c PDU has been received with an incorrect CRC, the MAC-c PDU is discarded. The size of the CRC field is 8 bits and the CRC is calculated as specified in section 4.2.1.1 in [16] or [19].

Figure 4.2.4.7-1: UTRAN side MAC architecture / MAC-is details for DCCH/DTCH transmission (SHO case, FDD only)

Figure 4.2.4.7-1a: UTRAN side MAC architecture / MAC-is details for 2 configured uplink frequencies (for DTCH and DCCH transmission, SHO case, FDD only)

Figure 4.2.4.7-2: UTRAN side MAC architecture / MAC-is details (TDD)

Figure 4.2.4.7-3: UTRAN side MAC architecture / MAC-is details (for CCCH transmission, FDD and 1.28 Mcps TDD only)

4.2.4.8 MAC-i entity – UTRAN Side

For TDD, and for FDD in CELL_DCH, there is one MAC-i entity in the Node B for each UE. For FDD, there is one MAC-i entity in the Node B for each common E-DCH resource. For 1.28 Mcps TDD in CELL-FACH state, there is one MAC-i entity in the Node B for each UE with dedicated E-RNTI, and one MAC-i entity in the Node B for each common E-RNTI. And there is one E-DCH scheduler function in the Node-B. When configured by the upper layers, the MAC-i and E-DCH scheduler handle HSUPA specific functions in the Node B. 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 subclauses 11.8.2.3 and 11.9.2.3 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. In FDD, for UEs in CELL_FACH state and Idle mode, the E-DCH control entity is additionally responsible for collision resolution and common E-DCH resource release by transmitting Scheduling Grants. The general principles of the E-DCH schedulling are described in subclauses 11.8.2.3 and 11.9.2.3 below.

– De-multiplexing:

This function provides de-multiplexing of MAC-i PDUs per E-DCH. For DTCH/DCCH transmission, MAC-is PDUs are forwarded to the associated MAC-d flow. For CCCH transmission (FDD and 1.28 Mcps TDD only), MAC-is PDUs are forwarded to the associated UL Common MAC flow.

– Read UE id (FDD only):
In CELL_DCH state, no UE ID is included in the MAC-PDU header.
In CELL_FACH, the E-RNTI is added in all MAC-i PDUs for DTCH/DCCH and NodeB triggered HS-DPCCH transmission at the UE side until the UE receives an E-AGCH with its E-RNTI (through an E-RNTI-specific CRC attachment).
In CELL_FACH state and in Idle mode, 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 FDD, there shall be one HARQ entity per E-DCH. For 1.28 Mcps TDD multi-carrier E-DCH operation, there is one HARQ entity per E-DCH transport channel.

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

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

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

Figure 4.2.4.8-2a: UTRAN side MAC architecture / MAC-i details for muliti-carrier E-DCH operation (for 1.28Mcps TDD)