|
3G/UMTS |
|||||||||||||||||||||
|
Channel Mapping : MAC-d
Comparing to LTE MAC structure, UMTS MAC operation and MAC PDU structure is very complicated. I don't think it is complicated because UMTS MAC is doing more things than LTE MAC. (In terms of functionalility, I think LTE MAC is doing more than UMTS MAC). I think most of the complexity of UMTS MAC structure come from the design and the complexity of the transport channel. Often, things get very confusing and as a result log analysis/troubleshooting gets very tricky. Followins are the topics that will be covered in this page.
As you see in 25.321 - Figure 4.2.4.1 (Overview on MAC Layer in UTRAN), regardless of whether it is for R99, HSDPA(R5), HSUPA(R6), HSPA+ (R7), every MAC data goes through MAC-d sublayer somewhere along it's path. However the data flow within this sublayer differs among R99, R5, R6, R7 and differs depending on whether it is uplink (From UE to UTRAN) or downlink (From UTRAN to UE).
To help you understand the path for each case, I colored the figure from 25.321 according to each of the case. Red path represent the case for R99 and it applies to both Uplink and downlink. But when you want to follow the uplink path, you have to read the figure from bottom to top and for downlink you have to read from top to bottom. The important thing to remember is that for R99 MAC-d is a whole of MAC layer and the MAC flow does not go through any further processing. Blue path indicate the path for HSDPA(R5) and HSPA+(R7). As you see, the data for HSDPA, HSPA+ goes through MAC-d with a very little processing and are passed to MAC-hs (HSDPA) or MAC-ehs(HSPA+) for further detailed processing. You will go back to this processing later in this section. Green path shows the path for HSUPA, meaning this is an uplink path. You have to follow from bottom (from the point labeled 'from MAC-es/MAC-is) to top.
< 25.321 - Figure 4.2.4.2.1 : UTRAN side MAC architecture / MAC-d details >
As you see in Figure 4.2.3.1 (Overview on MAC Layer in UE), regardless of whether it is for R99, HSDPA(R5), HSUPA(R6), HSPA+ (R7), every MAC data goes through MAC-d sublayer somewhere along it's path. However the data flow within this sublayer differs among R99, R5, R6, R7 and differs depending on whether it is uplink (From UE to UTRAN) or downlink (From UTRAN to UE).
To help you understand the path for each case, I colored the figure from 25.321 according to each of the case. Red path represent the case for R99 and it applies to both Uplink and downlink. But when you want to follow the uplink path(from UE to UTRAN), you have to read the figure from top to bottom and for downlink (from UTRAN to UE) you have to read from bottom to top. The important thing to remember is that for R99 MAC-d is a whole of MAC layer and the MAC flow does not go through any further processing. Blue path indicate the path for HSDPA(R5) and HSPA+(R7). As you see, the data for HSDPA, HSPA+ goes through MAC-d with a very little processing and are passed to MAC-hs (HSDPA) or MAC-ehs(HSPA+) for further detailed processing. You will go back to this processing later in this section.
< 25.321 - Figure 4.2.3.2.1 : UE side MAC architecture / MAC-d details >
General Structure of MAC-d PDU
The MAC PDU for R99 (marked in Red path) has following structure. (Note that this PDU applies only to R99 MAC PDU and does not apply to HSDPA, USUPA PDU. ) This is a generic format which contains all the possible fields in the header, but depending on logical channels and mapping type, the header structure gets different. We will see the details for each specific cases in next section.
< 25.321 - Figure 9.1.2.1 : MAC PDU >
The detailed value and meaning for each field are defined by various tables as shown below.
< 25.321 - Table 9.2.1.1 : Coding of the Target Channel Type Field on FACH for TDD >
< 25.321 - Table 9.2.1.2 : Coding of the Target Channel Type Field on FACH for FDD >
< 25.321 - Table 9.2.1.4 : Coding of the Target Channel Type Field on RACH for FDD >
< 25.321 - Table 9.2.1.4 : UE-ID Type field definition >
< 25.321 - Table 9.2.1.6 : Lengths of UE-ID Type field >
< 25.321 - Table 9.2.1.5a : Structure of the C/T field >
MAC PDU Structure for Each Logical Channel and Transport Channel
MAC-d PDU structure takes various different form depending on the type of Logical channel and the mapping between the logical channel and transport channel. In this section, I will summarize the MAC PDU structures for all the possible combinations. These are based on 25.321 - 9.2.1 MAC PDU: Parameters of the MAC PDU header (not HS-DSCH or E-DCH) and MAC-d PDU header (HS-DSCH and E-DCH)
< 25.321 - Figure 9.2.1.1.1: MAC PDU formats for DTCH and DCCH >
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. 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 C/T field is included in the MAC header if multiplexing on MAC is applied.
< 25.321 - Figure 9.2.1.4-1: MAC PDU format for CCCH mapped to RACH/FACH >
< 25.321 - Figure 9.2.1.2.1: MAC PDU formats 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. c) in FDD and 1.28 Mcps TDD, when BCCH mapped to HS-DSCH - the MAC-ehs header is included.
Example > Mapping DCCH onto FACH
This examaple came from the Cell Update Confirm (NB -> UE) message.
Example > Mapping CCCH onto RACH
|
|||||||||||||||||||||
