The functions of MAC can be summarized as follows:
If one has to look at the UMAC in terms of design perspective it will look as follows
Thus according to the above figure there are three interfaces/SAP to U-MAC. They are:
The MAC operates on the channels defined below; the transport channels are described between MAC and Layer 1, the logical channels are described between MAC and RLC.
Common transport channel types are:
Dedicated transport channel types are:
The MAC layer provides data transfer services on logical channels. A set of logical channel types is defined for different kinds of data transfer services as offered by MAC.
Each logical channel type is defined by what type of information is transferred.
Logical channel structure
The configuration of logical channel types is depicted in figure below.
Data Processing in UL and DL
U-MAC is part of the U-Plane of the UMTS protocol stack and so its performance influences the overall system performance. Processing of data, in particular in the UL, is time critical in that completion of the processing of UL data must be within a finite time and leave enough time for U-PHY to carry out its processing before transmitting the data over the air interface. Processing of data in the DL is less time critical and can be done on an 'as soon as possible' basis
To process the data in UL which is very time critical there is always some background processing in UMAC while it is preparing to send the data in UL. The background tasks and UL processing are initiated by a trigger called TTI. It's an event timer set to trigger U-MAC at each frame boundary (i.e. at 10ms intervals) so that there is 10ms left before data transmission on the air interface is to take place. UL data transfer is then initiated (i.e. TF and TFC selection) which results in UMAC_Status_IND primitive being sent to U-RLC.
Finally, traffic volume measurement takes place (therefore taking in to account the latest buffer occupancies in U-RLC). When the required data is received back from U-RLC it is processed and passed to U-PHY.
In the DL Data is received from U-PHY asynchronously with the data grouped by its TTI, i.e. each primitive contains data for a single TTI. UMAC after identifying that the dta is meant for this UE, will transfer the PDUs to URLC.
U-MAC's primary task is to carry data between U-PHY and U-RLC in both the UL and the DL. This task is of the highest priority. In the background, two other sets of tasks are also happening. Firstly, configuration primitives received from U-RRC are received asynchronously. Secondly, every frame (10ms), other tasks are initiated that need attention, i.e. traffic volume measurement, RACH access, activation of delayed configurations etc.
The basic UMAC architecture of UMAC is shown blow
As shown in the above figure UMAC consist of three different UMV entities which can be considered as different modules when implementing UMAC for UE.
In terms of design perspective the following section gives and idea what are the modules UMAC can have while implementing. Please note that this is just an idea of having certain modules in UMAC. Engineers can design and can implement modules different to what explained below.
This sub-component or module is responsible for handling all primitives received from, and sent to, U-RRC. So basically this can be implemented as file which will contain definition for all the data structures related to the primitives received from URRC. URRC SAP's header file contains the 'C' structures, that represent the configuration primitives, and is shared with U-RRC. The members of the structure will be the parameters of the primitives. The file will also contain the function definition and prototype for handling message to and from URRC.
All the primitives received through URRC SAP should contain primitive identifier. This will enable the developer to call the corresponding function to take the actions based on the received primitive.
On the transmitting side, the URRC SAP creates the final primitive and adds the primitive header before sending it to U-RRC.
This sub-component or module is responsible for handling all primitives received from, and sent to, U-PHY.
Primitives are received encapsulated by a primitive header within which is an identifier of the primitive
On the transmitting side, the U-PHY SAP creates the final primitive and adds the primitive header before sending the primitive to U-PHY.
U-PHY SAP's header file contains the 'C' structures, that represent the primitives and is shared with U-PHY.
The 'U-RLC SAP' sub-component is responsible for handling all primitives received from, and sent to, U-RLC.
If we consider a better design then I would recommend that this SAP should be only used in the DL. In DL the primitives are received with primitive identifier embedded into it. The correct function in the correct U-MAC sub-component (MAC-c/sh, MAC-d, MAC-b) is called passing the primitive itself. For data transmission primitives this needs the Radio Bearer number to be acquired from within the primitive to enable the appropriate mapping for the Radio Bearer to be identified from the configuration provided by the 'Database'. The primitive may then contain several instances, for example the data for several Radio Bearers. In this case the sub-component splits the primitive intelligently to handle the passing of the data to different sub-components (if required).
On the transmitting side, the U-RLC SAP creates the final primitive and adds the primitive header before sending the primitive to U-RLC. U-RLC SAP's header file contains the 'C' structures, that represent the primitives, and is shared with U-RLC.
In case of UL I will recommend that instead of passing the primitives in each TTI it's better to have the function calls. This is because it is felt that the performance of the protocol stack can be significantly improved by violating the principle of everything being handled by the U-RLC SAP. When U-MAC needs to get the data or PDUs from URLC in each TTI or if it needs to know the buffer occupancies in U-RLC, direct function calls are made so that the latest values are obtained. By using function calls, the other possible solution of extra primitives passing between the layers, and the extra delays that incurs at a critical time due to the overhead of the Protocol Stack Framework, is avoided. In a similar way, in the case of U-RLC TM Radio Bearers, U-MAC uses a function call to request the more detailed (than the pure buffer occupancies) information required about what is waiting in the U-RLC buffer.
This sub-component (can be given any other name) is responsible for initialising the U-MAC software ready for use by calling the initialisation procedures within each of the other sub-components. In other way this is the initialisation of the UMAC task. Please note that this is just the initialisation of the UMAC data structure or it's just a software initialisation. Following this U-MAC still needs to be configured by U-RRC, via the URRC SAP, before any data transfer can occur. This initialisation should occur when power is first applied to the processor or when the CUMAC_Initialisation_REQ primitive is received.
The initialization process can be viewed as initializing the data structure, allocating the necessary memory for the static buffers or primitives and so on. In this process most of the variables used in UMAC are initialized to their default values as suggested in the 3GPP specs.
This sub-component is responsible for halting the U-MAC software so that it uses the minimum of system resources.
The 'MAC-b' sub-component is responsible for handling of the broadcast information received in the DL on the BCH transport channel. It is initiated by the receipt of the UPHY_Data_IND primitive that has a data indication, within the primitive, with the Transport Channel Type set to BCH. There can be several instances of MAC-b (due to the possibility of there being several broadcast channels being monitored at one time). Due to the simplicity of the 'MAC-b' sub-component there is no requirement for instance context data. The 'Database' provides the configuration information to map the data to the correct BCCH so that the data can be passed to U-RLC with the UMAC_Data_IND primitive.
The 'MAC-c/sh' sub-component is responsible for processing of information on the common and shared transport channels in both the UL and the DL.
In terms of implementation and design it is initiated by one of two events.
NOTE: The RLC provides RLC-PDUs to the MAC, which fit into the available transport blocks on the transport channels.
When data is received from U-RLC in the UL, via the UMAC_Data_REQ primitive, the TCTF and UE ID (CRNTI is always added in UL but only for dedicated logical channel data) header fields are added and then the data is passed to the 'U-PHY SAP' sub-component for transmission to U-PHY.
In the DL (if multiple transport channels are received then this procedure is carried out for each transport channel), the TCTF field is stripped off the data. If the logical channel indicated by the TCTF field is for a common/shared logical channel then the data is passed up to U-RLC with the UMAC_Data_IND primitive. If the logical channel indicated by the TCTF field is for a dedicated logical channel then the UE ID field is stripped off the data. The UE ID is compared against the UE ID provided by the 'Database'. This can either be a U-RNTI, a C-RNTI or a DSCH-RNTI, the UE ID Type field gives the type (U-MAC has all three values, if available at the UE, configured in the 'Database'). If the two UE IDs do not match then the data is discarded. If the two UE IDs match then the data is de-multiplexed, if necessary, and then passed up to U-RLC, also with the UMAC_Data_IND primitive.
Thus the following functionality is covered by UMAC -c/sh:
There is one MAC-c/sh entity in each UE.
The 'MAC-d' sub-component is responsible for processing of information on dedicated transport channels in both the UL and the DL.
The following functionality is covered by MAC-d:
The MAC-d entity is responsible for mapping dedicated logical channels for the uplink either onto dedicated transport channels or to transfer data to MAC-c/sh to be transmitted via common channels.
One dedicated logical channel can be mapped simultaneously onto DCH and DSCH. One dedicated logical channel can be simultaneously mapped onto DCH and HS-DSCH. The MAC-d entity has a connection to the MAC-c/sh entity. This connection is used to transfer data to the MAC-c/sh to transmit data on transport channels that are handled by MAC-c/sh (uplink) or to receive data from transport channels that are handled by MAC-c/sh (downlink).
The MAC-d entity has a connection to the MAC-hs entity. This connection is used to receive data from the HS-DSCH transport channel which is handled by MAC-hs (downlink).
There is one MAC-d entity in the UE.
In terms of implementation and design perspective it is initiated by one of two events...
When data is received from U-RLC in the UL, via the UMAC_Data_REQ primitive, the mapping information is acquired from the 'Database'. The data is multiplexed with other logical channels on a block by block basis (with the C/T field added). The data is ciphered if required (again the 'Database' is queried to see if ciphering is configured for this particular Radio Bearer) and then the data is passed to U-PHY with the UPHY_DCH_Data_REQ primitive. Note that the UMAC_Data_REQ primitive received from U-RLC will have contained all of the dedicated logical channel data, therefore this procedure will be executed for each logical channel and the UPHY_DCH_Data_REQ primitive will include all the data to be sent on the single CCTrCh.
In the DL, for data received directly from U-PHY with the UPHY_Data_IND primitive the mapping and configuration is queried from the 'Database' for the transport channel the data is received on (if multiple transport channels are received in the UPHY_Data_IND primitive then this procedure is carried out for each transport channel). The data is de-multiplexed on a block by block basis (by stripping off and using the C/T field), deciphered if required before being passed to U-RLC with the UMAC_Data_IND primitive (with the correct Radio Bearer set within the primitive).
MAC-d has another final task, which is to handle loopback testing. When this mode is in operation U-MAC will echo the TBs received back to U-PHY with the addition of the CRC information of the received blocks appended. U-RRC should have provided the appropriate TFs to allow this to happen.
This module can be considered as a heart of the UMAC layer. The best way to implement this is to define a structure whose members are equivalent to the configuration parameters given my URRC once the UMAC task is initialised. The 'Database' sub-component processes and holds the information provided by U-RRC through the URRC SAP plus other information regarding the status of the U-MAC layer at a particular point in time (previous successful transmission of data on a logical channel etc.). It provides an intelligent interface to access information, for example to provide the TTI for each UL transport channel as well as straightforward access to the configuration information. It also provides the ability to handle configuration information that is not to be used until a specified time in the future and handle the switching of information (plus, for the special case of a TFCSS configuration, reverting back to the unmodified TFCS after the configured time). The following information is contained within the database:
When configurations are received by U-MAC from U-RRC they are not handled immediately but stored in a queue until immediately after the event timer trigger is received (via the 'Data Handler'). At the same time configurations that have been delayed further, due to possessing an activation time, are activated if the correct CFN has now arrived . The UMAC design should ensure that configurations do not change during processing of data (e.g. between the request of data from U-RLC with UMAC_Status_IND and the receipt of data with UMAC_Data_REQ).
As a good design please try to develop the habit that as much as possible of the configuration information stored by the 'Database' is stored as pointers to the primitive structures that have been received from U-RRC. The memory of the primitive structure is released when the configuration is no longer required. The pointers should be stored in static variables. When other sub-components request some information from the 'Database' then they receive the pointer to the primitive structure. This means that the sub-components of U-MAC also need to be able to share the CUMAC SAP's header file. However there are a couple of special exceptions that can be considered. Firstly, TFCS configurations and TFCSS configurations are handled by using the information provided to modify the already stored TFCS configuration primitive. Secondly, again with TFCS and TFCSS configurations, the information provided is decoded from the CTFC to the TFIs and stored like this therefore avoiding the need to decode the CTFCs every time Transport Format Combination Selection takes place.
Finally, the Database module should be intelligent enough to handle the arrival of different primitives at the same time.
This sub-component receives a frame tick via an event timer trigger configured to initiate U-MAC once every frame at the frame boundary. From this it informs other sub-components that need to be actioned to do something at this time. These are:
Transport Format Combination Selection
The 'Transport Format Combination Selection' module provides a Transport Format Combination Selection service for DCH transport channels to be mapped to a single CCTrCh. Some preparation of data for the Transport Format Combination Selection routine, that does not depend on information that changes every frame, is done as soon as configuration primitives are handled after receipt from U-RRC.
TFC selection is processor intensive, therefore limiting the amount of work done when we want to move data through the stack is desirable. Firstly, TFC selection is done on the transport channels whereas U-RRC configures U-MAC with Radio Bearers (which map one to one on to logical channels). The transport channel information (which logical channels are mapped to each transport channel) is therefore prepared at configuration time. Secondly, an array of TF information is prepared at configuration time to save the TFC selection from searching through each transport channel's TFS.
Transport Format Combination Selection needs to acquire the logical channel to transport channel mappings from the 'Database' sub-component, the TTIs of the transport channels and the buffer occupancies of the logical channels from U-RLC (via direct function calls) to make the selection. The logical channel priorities stored by the 'Database' in the Radio Bearer configurations are also taken in to account. There is also the facility for TFCs in the TFCS to be flagged as not being available if the estimated U-PHY power usage of a TFC is greater than the maximum UE transmit power. This is handled internally within the 'Database' so should not be visible to 'Transport Format Combination Selection'.
When the event timer trigger is received (via the 'Data Handler') then logical channel to DCH transport channel mappings are read from the 'Database', Transport Format Combination Selection is done and the required data is requested from U-RLC via the UMAC_Status_IND primitive or a function call. Note that in both cases, U-MAC calculates how much header information will be need to be added to the U-RLC data, during transmission, and subtracts this value from the TB sizes in the selected TFs. This new value is the one used in the UMAC_Status_IND primitives sent to U-RLC.
In the case of two or more DCH transport channels, with different TTIs, being multiplexed to a single CCTrCh (for example, if we have two DCH transport channels, one with a TTI of 10ms and another with a TTI of 20ms) every 20ms data for both transport channels will be transferred to U-PHY. However in the 'in-between frame', i.e. every other 10ms, data for only the transport channel with the TTI of 10ms will be transferred to U-PHY. This raise the big question which is what happens in the TFC selection when data is being transferred for only one of the two transport channels? The solution for this is to remember the TF selected (as part of the TFC) for the 20ms TTI transport channel in the last frame and ensure the use of the same TF in this frame. The other option from U-MAC's point of view would be to select a zero TF, i.e. one that does not contain any data format (zero size, no coding). The theory is that U-PHY will still need the 20ms TTI transport channel properly identified in the TFCI for encoding purposes (as the 20ms TTI transport channel data is physically transmitted over 20ms). Ditto for decoding purposes in the UTRAN's U-PHY. If, in another case, no transport channels' TTI coincides with the current frame then the Transport Format Combination selected for the last frame where there was data to send is to be used by U-PHY, however U-MAC will not bother informing U-PHY of this as it can be assumed. No data needs to be requested from U-RLC (although the UMAC_Status_IND primitive is still sent to U-RLC so that it knows the success or not of the last transmission on each RB).
Control of RACH transmissions
The 'Control of RACH transmissions' sub-component controls the timing of sending data to U-PHY plus selection of the Access Service Class of RACH transport channel information being passed to U-PHY.
When the event timer trigger (via the 'Scheduler') is received the sub-component determines whether there is old data waiting to be re-sent or new data is required. If new data is required then logical channel to RACH transport channel mappings are read from the 'Database' and Transport Format Selection is done. The required data is then requested from U-RLC via the UMAC_Status_IND primitive. Note that, like the 'Transport Format Combination Selection' sub-component, U-MAC calculates how much header information will be need to be added to the U-RLC data, during transmission, and takes this in to account in the UMAC_Status_IND primitive sent to U-RLC. If old data is to be re-sent then the 'Control of RACH transmissions' procedure is executed to determine whether it should send the data to U-PHY immediately or wait longer.
When U-MAC wants to transmit data on the RACH transport channel it needs to request access by sending the UPHY_RACH_Data_REQ primitive to U-PHY containing the data. If U-PHY receives a positive AICH signal then it transmits the RACH data to the UTRAN. U-PHY will then confirm whether the data was sent or, if not, the reason why not with the UPHY_RACH_Access_CNF primitive. This keeps the functionality of U-MAC working to a minimum granularity of a frame. In the case of an unsuccessful RACH transmission then a retry may occur in the next frame (initiated by the 'Scheduler' sub-component), dependant on the Control of RACH transmissions procedure. An identifier is attached to the UPHY_RACH_Data_REQ primitive so that U-PHY is aware that the data is being retried so that it may increase the preamble power.
Traffic Volume Measurements
The 'Traffic Volume Measurement' sub-component monitors the amount of information queued to be transmitted by U-MAC in the UL, providing reports to U-RRC as requested in the configuration of U-MAC by U-RRC.
It is initiated by the 'Scheduler' sub-component every 10ms at which time the 'Traffic Volume Measurement' sub-component, from the configuration held by the 'Database', finds out the buffer occupancies of all logical channels, mapped to the required transport channels to be monitored, via direct function calls to U-RLC. It then does the appropriate calculations and reports, if necessary, the traffic volume on all Radio Bearers to U-RRC with the CUMAC_Measurement_IND primitive (either the straightforward buffer occupancy, the buffer occupancy average over time or the buffer occupancy variance over time). The calculations also involve keeping track of the running averages and variances for each logical channel. The two triggers that initiate U-MAC to send a measurement report to U-RRC are measurements that occur at a defined period and / or measurements that go above or below specified configured values. When new measurements are configured then functions in the 'Traffic Volume Measurements' sub-component are called to initialise local variables and also to determine logical channel to transport channel mappings so that they do not have to be worked out when the measurements are to be calculated.
Data Flow through UMAC
The figure below shows the mapping of logical channels to transport channels.
In the case of dedicated channels (DCH, DTCH and DCCH) and FACH there can be multiple instances of each. It is also important to note that U-MAC does not distinguish between DTCH and DCCH - as far as U-MAC is concerned they are processed in the same manner.
When data enters U-MAC, either at the U-PHY SAP or the U-RLC SAP the SAP sub-component looks up routing information, in the Database, to decide which internal U-MAC sub-component needs to process the data.
Uplink Data Flow through UMAC
As soon as UMAC receives the trigger via the 'Data Handler' it triggers procedures in both the 'Control of RACH transmissions' and 'Transport Format Combination Selection' sub-components. These results in a single UMAC_Status_IND primitive being sent to U-RLC. The request can include information about multiple logical channels.
The 'Control of RACH transmissions' sub-component determines which logical channels are mapped to the RACH transport channel. If any logical channels are mapped it then acquires the buffer occupancy for each of those logical channels from U-RLC (via direct function calls) and does a Transport Format selection from the configured RACH TFS. Both CCCH and DTCH/DCCH may be mapped to RACH, so the UMAC_Status_IND primitive is sent to U-RLC (via U-RLC SAP) requesting the appropriate amount of data for both.
The 'MAC-d' sub-component determines which logical channels are mapped to the DCHs, acquires the buffer occupancy for each of those logical channels from U-RLC (again via direct function calls to U-RLC) and does a Transport Format Combination selection from the configured DCH TFCS. The UMAC_Status_IND primitive is then sent (again via U-RLC SAP) requesting the appropriate amout of data for the DTCH/DCCHs.
Note that the two sub-components should send a request to U-RLC SAP even if no actual data is required, so that U-RLC SAP knows this and can send the UMAC_Status_IND primitive to U-RLC at the right time. Also included in the UMAC_Status_IND primitive is a boolean that provides details to U-RLC about whether the last transmission on each particular logical channel was successful or not. This is only regarding the data being passed to U-PHY and so is really only of use for RACH transport channel data. After a transmission, in the case of there being no data actually to send in the next frame from the logical channel then the primitive is sent anyway but requesting zero data.
The Buffer Occupancy request for UM and AM Radio Bearers returns the number of bytes waiting in U-RLC for that Radio Bearer. For TM Radio Bearers the size of the next SDU plus the number of SDUs of that size is returned. This is due to the different way that TM works in relation to UM and AM, by not allowing segmentation in U-RLC. U-MAC is provided with the U-RLC mode by U-RRC, in the Radio Bearer configuration.
Although U-RRC provides a logical channel priority to U-MAC for CCCH it is actually fixed to one (specified in the U-RRC 3GPP specification) so in practise CCCH data will take priority over DTCH/DCCH data (one being the highest logical channel priority possible).
Uplink Data, Common logical channel to common Tr channel
In this the CCCH (logical channel) data that is to be sent on the RACH transport channel. The data received from URLC will immediately be processed by MAC-c/sh and passed on to U-PHY.
Uplink, dedicated logical mapped to common Tr channel
In this case DTCH/DCCH data has to be sent on the RACH transport channel. In this scenario there can be several DTCH/DCCHs may be multiplexed. The incoming data from URLC is multiplexed by MAC-c/sh, then the appropriate headers are added and the data is passed on to U-PHY.
Uplink, common logical channel mapped to dedicated or common logical channel mapped to common Tr channel
In this scenario the requirement will be that both CCCH logical channel data and DTCH/DCCH logical channel data is to be sent on the RACH transport. It thus combines the previous two cases.
Uplink, dedicated logical channel mapped to dedicated Tr channel
The DTCH/DCCH logical channel data is to be sent on DCH transport channels. The incoming data is immediately processed by MAC-d and passed on to U-PHY. As all the logical channels were requested in a single UMAC_Status_IND primitive then all the data for the logical channels is received in a single UMAC_Data_REQ primitive. The transport channel data is transferred to U-PHY as a single UPHY_Data_REQ primitive (i.e. all of the data for a single CCTrCh is sent together).
Downlink data flow
In the DL it is much more straightforward as data is received from U-PHY with the UPHY_Data_IND primitive asynchronously. Each UPHY_Data_IND primitive contains data for a single TTI. The data is processed as soon as possible and passed to U-RLC with a single UMAC_Data_IND primitive. If U-PHY sends several transport channels in a single primitive then each will be processed sequentially within the single STF. The U-PHY SAP will separate transport channel data that is to be sent to different U-MAC sub-components (i.e. 'MAC-b', 'MAC-c/sh' and 'MAC-d') and transfer only the data appropriate to that sub-component. After processing U-MAC will collate the data in U-RLC SAP - i.e. the primitive will include the data for all of the logical channels being sent due to the data with a particular TTI in an incoming UPHY_Data_IND. The different scenarios which can happen DL in terms of mapping of logical channel to transport channel are as follows:
Identification of Logical Channel Type from Radio Bearer ID
No U-RRC messages defined in the U-RRC 3GPP specification contain the Logical Channel Type. This means that when UE U-RRC receives the Radio Bearer configuration from UTRAN U-RRC it has no information about the Logical Channel Type used for each Radio Bearer (whereas there is a Transport Channel Type so that information is known). Therefore how can U-MAC be given the information to map a Logical Channel Type to a Transport Channel Type? The answer is that in the UE the Logical Channel Type can be inferred from the Radio Bearer ID. For Radio Bearers 0 through 4 the Logical Channel Type is specified in the U-RRC 3GPP specification section 6.3. For Radio Bearers 5 through 31 the Logical Channel Type is always DCCH or DTCH (which U-MAC does not distinguish between). In the DL Radio Bearer IDs are not specified in the 3GPP specifications for some of the common logical channels. However, for our implementation negative values have been assigned. The table below illustrates the above facts.
Elements for layer-to-layer communication
The interaction between the MAC layer and other layers are described in terms of primitives where the primitives represent the logical exchange of information and control between the MAC layer and other layers. The primitives shall not specify or constrain implementations. The MAC is connected to layer 1, RLC and RRC. The following subclauses describe the primitives between these layers.
Primitives between MAC and RLC The primitives between MAC layer and RLC layer are shown in table below.
Parameters in primitives between MAC and RLC
a) Data: It contains the RLC layer messages (RLC-PDU) to be transmitted, or the RLC layer messages that have been received by the MAC sub-layer.
b) Number of transmitted transport blocks (No_TB) : indicates the number of transport blocks transmitted by the peer entity within the transmission time interval, based on the TFI value.
c) Buffer Occupancy (BO): the parameter Buffer Occupancy (BO) indicates for each logical channel the amount of data in number of bytes that is available for transmission and retransmission in RLC layer. When MAC is connected to an AM RLC entity, control PDUs to be transmitted and RLC PDUs outside the RLC Tx window shall also be included in the BO. RLC PDUs that have been transmitted but not negatively acknowledged by the peer entity shall not be included in the BO.
d) RX Timing Deviation (TD), TDD only: it contains the RX Timing Deviation as measured by the physical layer for the physical resources carrying the data of the Message Unit. This parameter is optional and only for Indication. It is needed for the transfer of the RX Timing Deviation measurement of RACH transmissions carrying CCCH data to RRC.
e) Number of PDU (No_PDU): specifies the number of PDUs that the RLC is permitted to transfer to MAC within a transmission time interval.
f) PDU Size (PDU_Size): specifies the size of PDU that can be transferred to MAC within a transmission time interval.
g) UE-ID Type Indicator: indicates the UE-ID type to be included in MAC for a DCCH and DTCH when they are mapped onto a common transport channel (i.e. FACH, RACH, DSCH in FDD or CPCH). On the UE side UE-ID Type Indicator shall always be set to C-RNTI.
h) TX status: when set to value "transmission unsuccessful" this parameter indicates to RLC that transmission of an RLC PDU failed in the previous Transmission Time Interval, when set to value "transmission successful" this parameter indicates to RLC that the requested RLC PDU(s) has been submitted for transmission by the physical layer.
i) RLC Entity Info: indicates to MAC the configuration parameters that are critical to TFC selection depending on its mode and the amount of data that could be transmitted at the next TTI. This primitive is meant to insure that MAC can perform TFC selection (see subclause 11.4).
j) Error indication: When a MAC SDU is delivered to upper layer, an error indication is given for the SDU to upper layer if an error indication for the SDU has been received from lower layer.
k) Status_Report_REQ: indicates to all AM RLC entities mapped on HS-DSCH to generate a status report when the MAC-hs resets.
Primitives between MAC and RRC
The primitives between MAC and RRC are shown in table below.
Parameters in primitives between MAC and RRC
a) UE information elements: S-RNTI, SRNC identity, C-RNTI, Activation time
b) RB information elements: RB multiplexing info (Transport channel identity, Logical channel identity, MAC logical channel priority)
c) TrCH information elements: Transport Format Combination Set, MAC-hs reset indicator, Re-ordering release timer (T1)
d) Measurement information elements: Reporting Quantity identifiers Time interval to take an average or a variance (applicable when Average or Variance is Reporting Quantity)
e)Measurement result: Reporting Quantity
f) Status info: when set to value ""transmission unsuccessful"" this parameter indicates to RRC that transmission of a TM RLC PDU failed (due to e.g. Maximum number of preamble ramping cycles reached for RACH in FDD), when set to value "transmission successful" this parameter indicates to RRC that the requested TM RLC PDU(s) has been submitted for transmission by the physical layer.
g) RACH transmission control elements: Set of ASC parameters (identifier for PRACH partitions, persistence values), Maximum number of preamble ramping cycles (FDD) or synchronisation attempts (1.28 Mcps TDD) Mmax, Minimum and maximum number of time units between two preamble ramping cycles, NBO1min and NBO1max (FDD only), ASC for RRC CONNECTION REQUEST message
h) Ciphering elements: Ciphering mode, Ciphering key, Ciphering sequence number
i) CPCH transmission control elements: CPCH persistency value, P for each Transport Format, Maximum number of preamble ramping cycles N_access_fails, NF_max (Maximum number of frames for CPCH transmission for each Transport Format), N_EOT (Number of EOT for release of CPCH transmission), Backoff control timer parameters, Transport Format Set, Initial Priority Delays, Channel Assignment Active indication
Elements for peer-to-peer communication
Protocol data units
A MAC PDU is a bit string, with a length not necessarily a multiple of 8 bits. Generally the bit string is to be read from left to right and then in the reading order of the lines.
Depending on the provided service, MAC SDUs are bit strings with any non-null length, or bit strings with an integer number of octets in length. An SDU is included into a MAC PDU from first bit onward.
In the UE for the uplink, all MAC PDUs delivered to the physical layer within one TTI are defined as Transport Block Set (TBS). It consists of one or several Transport Blocks, each containing one MAC PDU. The Transport Blocks, shall be transmitted in the order as delivered from RLC. When multiplexing of RLC PDUs from different logical channels is performed on MAC, the order of all Transport Blocks originating from the same logical channel shall be the same as the order of the sequence delivered from RLC. The order of the different logical channels in a TBS is set by the MAC protocol.
MAC PDU (non-HS-DSCH)
A MAC PDU consists of an optional MAC header and a MAC Service Data Unit (MAC SDU) see figure below.
Both the MAC header and the MAC SDU are of variable size. The content and the size of the MAC header depends on the type of the logical channel, and in some cases none of the parameters in the MAC header are needed. The size of the MAC-SDU depends on the size of the RLC-PDU, which is defined during the setup procedure.
MAC-d PDU (HS-DSCH)
For HS-DSCH the MAC-d PDU format equals the MAC PDU format for the non HS-DSCH case.
MAC PDU (HS-DSCH)
In case of HS-DSCH a MAC PDU consists of one MAC-hs header and one or more MAC-hs SDUs where each MAC-hs SDU equals a MAC-d PDU. A maximum of one MAC-hs PDU can be transmitted in a TTI per UE. The MAC-hs header is of variable size. The MAC-hs SDUs in one TTI belongs to the same reordering queue.
Formats and parameters NOTE: MAC header field encodings as specified in this clause with designation "Reserved" are forbidden to be used by a sender in this version of the protocol.
MAC PDU: Parameters of the MAC PDU header (non HS-DSCH) and MAC-d PDU header (HS-DSCH)
The following fields are defined for the MAC header for transport channels other than HS-DSCH and for the MAC-d PDU header for HS-DSCH:
MAC header for DTCH and DCCH (not mapped on HS-DSCH)
a) DTCH or DCCH mapped to DCH, no multiplexing of dedicated channels on MAC: no MAC header is required.
b) DTCH or DCCH mapped to DCH, with multiplexing of dedicated channels on MAC: C/T field is included in MAC header.
c) DTCH or DCCH mapped to RACH/FACH: TCTF field, C/T field, UE-Id type field and UE-Id are included in the MAC header. For FACH, the UE-Id type field used is the C-RNTI or U-RNTI. For RACH, the UE-Id type field used is the C-RNTI.
d) DTCH or DCCH mapped to DSCH or USCH: the TCTF field is included in the MAC header for TDD only. The UE-Id type and UE-Id are included in the MAC header for FDD only. The UE-Id type field used is the DSCH-RNTI. The C/T field is included if multiplexing on MAC is applied.
e) DTCH or DCCH mapped to DSCH or USCH where DTCH or DCCH are the only logical channels: the UE-Id type and UE-Id are included in the MAC header for FDD only. The UE-Id type field used is the DSCH-RNTI. The C/T field is included in the MAC header if multiplexing on MAC is applied.
f) DTCH or DCCH mapped to CPCH: UE-Id type field and UE-Id are included in the MAC header. The C/T field is included in the MAC header if multiplexing on MAC is applied. The UE-Id type field used is the C-RNTI.
MAC PDU formats for DTCH and DCCH
MAC-d Header for DTCH and DCCH (mapped on HS-DSCH)
The MAC-d PDU header for DTCH and DCCH mapped on HS-DSCH is as shown in figure below.
C/T field is included in the MAC-d PDU header if multiplexing on MAC is applied.
MAC-d PDU format for DTCH and DCCH mapped on HS-DSCH
MAC header for BCCH
a) BCCH mapped to BCH: no MAC header is included.
b) BCCH mapped to FACH: the TCTF field is included in MAC header.
MAC PDU formats for BCCH
MAC header for PCCH
There is no MAC header for PCCH.
MAC header for CCCH
CCCH mapped to RACH/FACH: TCTF field is included in MAC header.
MAC PDU formats for CCCH
MAC Header for CTCH
The TCTF field is included as MAC header for CTCH as shown in figure below.
MAC PDU format for CTCH
MAC Header for SHCCH
The MAC header for SHCCH is as shown in figure below.
MAC PDU format for SHCCH
a) SHCCH mapped to RACH and USCH/FACH and DSCH: TCTF has to be included.
b) SHCCH mapped to RACH and USCH/FACH and DSCH, where SHCCH is the only channel.
MAC PDU: Parameters of the MAC header (HS-DSCH)
MAC header for DTCH and DCCH
a) DTCH or DCCH mapped to HS-DSCH: The Queue ID field and TSN field are always included in the MAC-hs header. One SID field, N field and F field is included for each MAC-d PDU size included in the MAC-hs PDU. Padding is not explicitly indicated but is included in the end of the MAC-hs PDU if the total size of the MAC-hs payload plus the MAC-hs header is smaller than the transport block set size.
 3GPP TS 25.321: Medium Access Control (MAC) protocol specification
 3GPP TS 25.301: Radio Interface Protocol Architecture
 3GPP TS 23.110: UMTS Access Stratum; Services and Functions
 3GPP TS 25.401: RAN Overall Description
 Introduction to 3G Mobile Communications - Juha Korhonen
 3GPP TS 25.331: RRC Protocol Specification