3G-UMTS MAC

Introduction to 3G/UMTS MAC

By Devendra Sharma

UMAC Basics Functional Overview The functions of MAC can be summarized as follows: mapping between logical channels and transport channels; selection of appropriate Transport Format for each Transport Channel depending on instantaneous source rate; priority handling between data flows of one UE; priority handling between UEs by means of dynamic scheduling; identification of UEs on common transport channels; U-MAC provides the UE identification along with dedicated logical channel data that is to be sent on common transport channels. In reverse it monitors dedicated logical channel data being received on common transport channels so that data directed at particular UE identification can be recognised and processed. Common logical channel data does not have to have UE identification added or recognised because either the data is purely common to all UEs or the UE identification is held within a higher layer message held in the data. multiplexing/demultiplexing of upper layer PDUs into/from transport blocks delivered to/from the physical layer on common transport channels; multiplexing/demultiplexing of upper layer PDUs into/from transport block sets delivered to/from the physical layer on dedicated transport channels; traffic volume measurement; Every now and then UMAC request URLC the amount of data to be sent. UMAC informs about this to URRC telling about the traffic waiting to be sent on that particular radio bearer. Based on this URRC configures UMAC allowing to act accordingly so that it can send the right amount of data to UPHY. This provision of data transfer service of UMAC can be likened to providing a pipe whose width U-MAC can adjust within a certain range. If there is a requirement for a width of pipe outside of this range then U-MAC informs U-RRC (U-RRC configures U-MAC to monitor the amount of data waiting to be sent by U-RLC via a variety of methods). If too much data is waiting, U-RRC can provide different options to enable more data to be sent. In reverse, if little data is waiting then U-RRC can provide different options that limit the amount of data able to be sent (therefore limiting the amount of radio resources being used). U-MAC is therefore providing control on an inner loop (or micro level) whereas U-RRC is providing control on an outer loop (or macro level). Transport Channel type switching; ciphering for transparent mode RLC; As URLC doesn't add any header to the data in TM mode the ciphering is done in UMAC. For UM and AM mode ciphering is done in URLC. Access Service Class selection for RACH and CPCH transmission; control of HS-DSCH transmission and reception including support of HARQ; HS-DSCH Provided Bit Rate measurement. 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: URRC SAP Interface: This interface provided the primitives between URRC and UMAC. The primitives are configuration primitives by whom the U-RRC layer can configure the U-MAC layer, both at start up and during operation of the layer. U-PHY SAP interface: This interface provided the primitives which are service primitives. Through these primitives data and control information is passed between the U-PHY and U-MAC layers. URLC SAP interface: The primitives between URLC and UMAC are service primitives by which data and control information is passed between the U-MAC and U-RLC layers. Channel structure 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. Transport channels Common transport channel types are: Random Access Channel(s) (RACH); Forward Access Channel(s) (FACH); Downlink Shared Channel(s) (DSCH); High Speed Downlink Shared Channel(s) (HS-DSCH); Common Packet Channel(s) (CPCH) for UL FDD operation only; Uplink Shared Channel(s) (USCH), for TDD operation only; Broadcast Channel (BCH); Paging Channel (PCH). Dedicated transport channel types are: Dedicated Channel (DCH). Logical Channels 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. MAC Overview 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. URRC SAP 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. U-PHY SAP 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. U-RLC SAP 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. Create UMAC 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. Kill UMAC This sub-component is responsible for halting the U-MAC software so that it uses the minimum of system resources. MAC-b (mac_b) 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. MAC-c/sh (mac_csh) 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. In UL common/shared transport channel data is received by U-MAC from U-RLC (via the UMAC_Data_REQ primitive, that has a data request within the primitive with the Radio Bearer ID set to a value whose logical channel maps on to a common/shared transport channel. In DL common/shared transport channel data is received by U-MAC from U-PHY (via the UPHY_Data_IND primitive that has a data indication within the primitive with the Transport Channel Type set to DSCH, PCH or FACH). Data with an invalid CRC is discarded. 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: TCTF MUX: this function represents the handling (insertion for uplink channels and detection and deletion for downlink 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; add/read UE Id: the UE Id is added for CPCH and RACH transmissions the UE Id, when present, identifies data to this UE. UL: TF selection: in the uplink, the possibility of transport format selection exists. In case of CPCH transmission, a TF is selected based on TF availability determined from status information on the CSICH; ASC selection: For RACH, MAC indicates the ASC associated with the PDU to the physical layer. For CPCH, MAC may indicate the ASC associated with the PDU to the Physical Layer. This is to ensure that RACH and CPCH messages associated with a given Access Service Class (ASC) are sent on the appropriate signature(s) and time slot(s). MAC also applies the appropriate back-off parameter(s) associated with the given ASC. When sending an RRC CONNECTION REQUEST message, RRC will determine the ASC; in all other cases MAC selects the ASC; scheduling /priority handling this functionality is used to transmit the information received from MAC-d on RACH and CPCH based on logical channel priorities. This function is related to TF selection. TFC selection transport format and transport format combination selection according to the transport format combination set (or transport format combination subset) configured by RRC is performed, There is one MAC-c/sh entity in each UE. MAC-d (mac_d) 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: 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: The C/T MUX is used when multiplexing of several dedicated logical channels onto one transport channel (other than HS-DSCH) or one MAC-d flow (HS-DSCH) is used. An unambiguous identification of the logical channel is included. 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]. UL TFC selection: Transport format and transport format combination selection according to the transport format combination set (or transport format combination subset) configured by RRC is performed. 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... Dedicated transport channel data is received by U-MAC from U-RLC (via the UMAC_Data_REQ primitive, that has a data request within the primitive with the Radio Bearer ID set to a value whose logical channel maps on to a dedicated transport channel. Dedicated transport channel data is received by U-MAC from U-PHY (via the UPHY_Data_IND primitive that has a data indication within the primitive with the Transport Channel Type set to DCH). Data with an invalid CRC is discarded. 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. Database 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: Radio Bearer configurations. Transport Format Sets. Transport Format Combination Set. Transport Format Combination Subset. Traffic Volume Measurement Configurations. Random Access Channel transmission control elements. Ciphering details. HFN details. CODEC details. Test loop status. Success of transmission of logical channel data in the last Transmission Time Interval. 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. Data Handler 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: The 'Database' sub-component. New configurations or configurations that are awaiting a CFN that matches their activation time are handled. The 'Control of RACH transmissions' sub-component. RACH accesses that previously failed need to be re-attempted (if the RACH access procedure allows it). If a new transmission is allowed then Transport Format Selection takes place and a request made for data from U-RLC with the UMAC_Status_IND primitive. The 'Transport Format Combination Selection' sub-component. Transport Format Combination Selection takes place and a request made for data from U-RLC with the UMAC_Status_IND primitive. The 'Traffic Volume Measurement' sub-component. The traffic volume for each UL transport channel needs to be checked every frame and measurements reported to U-RRC if necessary. 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 Uplink Initiation 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: Downlink, BCH to BCCH Downlink, FACH to BCCH Downlink, FACH to BCCH Downlink, PCH to PCCH Downlink, FACH to CCCH Downlink, DSCH/FACH to DTCH/DCC Downlink, dedicated to dedicated 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. Radio Bearer Logical Channel inferred RB 0 CCCH RB 1 DCCH RB 2 DCCH RB 3 DCCH RB 4 DCCH RB 5..32 DTCH or DCCH 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. Generic Name Parameter Request Indication Response Confirm MAC-DATA Data, BO, UE-ID type indicator, RLC Entity Info Data, No_TB, TD (note), Error indication MAC-STATUS No_PDU, PDU_Size, TX status,Status_Report_REQ BO, RLC Entity Info NOTE:                TDD only. MAC-DATA-Req/Ind: MAC-DATA-Req primitive is used to request that an upper layer PDU be sent using the procedures for the information transfer service; MAC-DATA-Ind primitive indicates the arrival of upper layer PDUs received within one transmission time interval by means of the information transfer service. MAC-STATUS-Ind/Resp: MAC-STATUS-Ind primitive indicates to RLC for each logical channel the rate at which it may transfer data to MAC. Parameters are the number of PDUs that can be transferred in each transmission time interval and the PDU size; it is possible that MAC would use this primitive to indicate that it expects the current buffer occupancy of the addressed logical channel in order to provide for optimised TFC selection on transport channels with long transmission time interval. At the UE, MAC-STATUS-Ind primitive is also used to indicate from MAC to RLC that MAC has requested data transmission by PHY (i.e. PHY-DATA-REQ has been submitted, see Fig. 11.2.2.1), or that transmission of an RLC PDU on RACH or CPCH has failed due to exceeded preamble ramping cycle counter. MAC-STATUS-Resp primitive enables RLC to acknowledge a MAC-STATUS-Ind. It is possible that RLC would use this primitive to indicate that it has nothing to send or that it is in a suspended state or to indicate the current buffer occupancy to MAC. 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. Generic Name Parameter Request Indication Response Confirm CMAC-CONFIG UE information elements, RB information elements, TrCH information elements, RACH transmission control elements, Ciphering elements, CPCH transmission control elements CMAC-MEASUREMENT Measurement information elements Measurement result CMAC-STATUS Status info CMAC-CONFIG-Req: CMAC-CONFIG-Req is used to request for setup, release and configuration of a logical channel, e.g. RNTI allocation, switching the connection between logical channels and transport channels, TFCS update or scheduling priority of logical channel. CMAC-MEASUREMENT-Req/Ind: CMAC-MEASUREMENT-Req is used by RRC to request MAC to perform measurements, e.g. traffic volume measurements; CMAC-MEASUREMENT-Ind is used to notify RRC of the measurement result. CMAC-STATUS-Ind: CMAC-STATUS-Ind primitive notifies RRC of status information. 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 General 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: Target Channel Type Field: The TCTF field is a flag that provides identification of the logical channel class on FACH and RACH transport channels, i.e. whether it carries BCCH, CCCH, CTCH, SHCCH or dedicated logical channel information. The size and coding of TCTF for FDD and TDD are shown in tables 1, 2, 3, 4 and 5. Note that the size of the TCTF field of FACH for FDD is either 2 or 8 bits depending of the value of the 2 most significant bits and for TDD is either 3 or 5 bits depending on the value of the 3 most significant bits. The TCTF of the RACH for TDD is either 2 or 4 bits depending on the value of the 2 most significant bits. Table 1: Coding of the Target Channel Type Field on FACH for TDD TCTF Designation 000 BCCH 001 CCCH 010 CTCH 01100 DCCH or DTCH over FACH 01101- 01111 Reserved (PDUs with this coding will be discarded by this version of the protocol) 100 SHCCH 101-111 Reserved (PDUs with this coding will be discarded by this version of the protocol) Table 2: Coding of the Target Channel Type Field on FACH for FDD TCTF Designation 00 BCCH 01000000 CCCH 01000001-01111111 Reserved (PDUs with this coding will be discarded by this version of the protocol) 10000000 CTCH 10000001- 10111111 Reserved (PDUs with this coding will be discarded by this version of the protocol) 11 DCCH or DTCH over FACH Table 3: Coding of the Target Channel Type Field on USCH or DSCH (TDD only) TCTF Designation 0 SHCCH 1 DCCH or DTCH over USCH or DSCH Table 4: Coding of the Target Channel Type Field on RACH for FDD TCTF Designation 00 CCCH 01 DCCH or DTCH over RACH 10-11 Reserved (PDUs with this coding will be discarded by this version of the protocol) Table 5: Coding of the Target Channel Type Field on RACH for TDD TCTF Designation 00 CCCH 0100 DCCH or DTCH Over RACH 0101- 0111 Reserved (PDUs with this coding will be discarded by this version of the protocol) 10 SHCCH 11 Reserved (PDUs with this coding will be discarded by this version of the protocol) C/T field: The C/T field provides identification of the logical channel instance when multiple logical channels are carried on the same transport channel (other than HS-DSCH) or same MAC-d flow (HS-DSCH). The C/T field is used also to provide identification of the logical channel type on dedicated transport channels and on FACH and RACH when used for user data transmission. The size of the C/T field is fixed to 4 bits for both common transport channels and dedicated transport channels. Table below shows the 4-bit C/T field. Table : Structure of the C/T field C/T field Designation 0000 Logical channel 1 0001 Logical channel 2 ... ... 1110 Logical channel 15 1111 Reserved (PDUs with this coding will be discarded by this version of the protocol) UE-Id: The UE-Id field provides an identifier of the UE on common transport channels. The following types of UE-Id used on MAC are defined: UTRAN Radio Network Temporary Identity (U-RNTI) may be used in the MAC header of DCCH using RLC UM (SRB1), when mapped onto common transport channels in downlink direction; the U-RNTI is never used in uplink direction; Cell Radio Network Temporary Identity (C-RNTI) is used on DTCH and DCCH in uplink, and may be used on DCCH in downlink and is used on DTCH in downlink when mapped onto common transport channels, except when mapped onto DSCH transport channel; In FDD, DSCH Radio Network Temporary Identity (DSCH-RNTI) is used on DTCH and DCCH in downlink when mapped onto DSCH transport channel;- the UE id to be used by MAC is configured through the MAC control SAP. The lengths of the UE-id field of the MAC header are given in table below. Table : Lengths of UE Id field UE Id type Length of UE Id field U-RNTI 32 bits C-RNTI 16 bits DSCH-RNTI 16 bits UE-Id Type: The UE-Id Type field is needed to ensure correct decoding of the UE-Id field in MAC Headers. Table : UE-Id Type field definition UE-Id Type field 2 bits UE-Id Type 00 U-RNTI 01 C-RNTI or DSCH-RNTI 10 Reserved (PDUs with this coding will be discarded by this version of the protocol) 11 Reserved (PDUs with this coding will be discarded by this version of the protocol) 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) Version Flag (VF): The VF field is a one bit flag providing extension capabilities of the MAC-hs PDU format. The VF field shall be set to zero and the value one is reserved in this version of the protocol. Queue identifier (Queue ID): The Queue ID field provides identification of the reordering queue in the receiver, in order to support independent buffer handling of data belonging to different reordering queues. The length of the Queue ID field is 3 bit. Transmission Sequence Number (TSN): The TSN field provides an identifier for the transmission sequence number on the HS-DSCH. The TSN field is used for reordering purposes to support in-sequence delivery to higher layers. The length of the TSN field is 6 bit. Size index identifier (SID): The SID fields identifies the size of a set of consecutive MAC-d PDUs. The MAC-d PDU size for a given SID is configured by higher layers and is independent for each Queue ID. The length of the SID field is 3 bit. Number of MAC-D PDUs (N): The number of consecutive MAC-d PDUs with equal size is identified with the N field. The length of the N field is 7 bits. In FDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 70. In 1.28 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 45. In 3.84 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 318. If more PDUs than the defined maximum number of PDUs for the corresponding mode are received, the UE behaviour is unspecified. Flag (F): The F field is a flag indicating if more fields are present in the MAC-hs header or not. If the F field is set to "0" the F field is followed by an additional set of SID, N and F fields. If the F field is set to "1" the F field is followed by a MAC-d PDU. The maximum number of MAC-hs header extensions, i.e. number of fields F set to "0", in a single TTI shall be assumed to be 7. If more extensions than the maximum defined for the corresponding mode are included in a TTI, the UE behaviour is unspecified. 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. References [1] 3GPP TS 25.321: Medium Access Control (MAC) protocol specification [2] 3GPP TS 25.301: Radio Interface Protocol Architecture [3] 3GPP TS 23.110: UMTS Access Stratum; Services and Functions [4] 3GPP TS 25.401: RAN Overall Description [5] Introduction to 3G Mobile Communications - Juha Korhonen [6] 3GPP TS 25.331: RRC Protocol Specification