HSUPA splits the uplink MAC into two layers, and the split is different on the two sides. The UTRAN puts MAC-e in the Node B and MAC-es in the SRNC. The UE has one combined MAC-e/es entity. Release 8 added a second pair, MAC-i and MAC-is, and RRC decides which pair a UE uses.
This page walks through the 25.321 architecture figures for both sides, then the PDU formats. It ends with how to decode a MAC-e PDU by hand and how MAC-i/is changes the picture.
Followings are the topics to be covered in this page.
- Overview on MAC-e/es/i/is in UTRAN : HSUPA
- Overview on MAC-e/es and MAC-i/is in UE : HSUPA
- How is a MAC-e PDU decoded step by step ?
- How does MAC-i/is differ from MAC-e/es ?
- Reference
Overview on MAC-e/es/i/is in UTRAN : HSUPA
This is about HSUPA processing on UTRAN side. This process is so complicated and multiple modules get involved in this process. I strongly recommend you to revisit < Overview on MAC Layer in UTRAN >, go through Figure 4.2.4-1 and get familiar to HSUPA path as much as possible.
You would see the two blocks in figure 4.2.4-1. MAC-e/i at the bottom left part and MAC-es/is at top right side. HSUPA data goes through MAC-e/i first and then go to MAC-es/is.
As you will see from the following figures, MAC-e is more focused on L1 specific process like HARQ and Grant/ACK-NACK transmission. These processes requires a lot of real time processing power, so MAC-e is located in Node B.
On the contrary MAC-es is doing reordering and disassemble the MAC-e PDUs into multiple MAC-d PDU which does not require such a tight real time process. So this module is located in RNC.
The first question is "The data goes through MAC-e and MAC-i simultaneously ?" and "The data goes through MAC-es and MAC-is simultaneously ?".
The answer is NO. The HSUPA data goes through only one of the path. It has only two of the combination as follows :
i) MAC-e ---> MAC-es
ii) MAC-i ---> MAC-is
So you have to study MAC-e/MAC-es path and MAC-i/MAC-is path separately.
Then the next question is how UE can determine which path to follow ? This decision comes from the higher layer signaling message.
The message is an RRC message that adds or reconfigures the E-DCH, for example a Radio Bearer Setup. It carries the IE "UL MAC header type" of 25.331 clause 10.3.5.2. If the IE is present, MAC-i/is is used. If it is absent, MAC-e/es is used. The last section of this page shows the ASN.1.
I think I have to update this sections for quite often since there are many details I have to revisit. For now, I will try to create a big picture. (When you read this figure, you should be careful about the direction. For the path marked in Black lines, you have to follow from the bottom to the top and for the path marked in red, you should follow from top to the bottom).
< 25.321 - Figure 4.2.4.5-1a : UTRAN side MAC architecture / MAC-e details(FDD) >
E-DCH Scheduling : drawn outside the MAC-e box, because there is one scheduler per Node B for all UEs. The MAC-e box itself is per UE.E-DCH Control : receives the scheduling requests and sends the grants. Its red dashed line goes down to E-AGCH and E-RGCH, and its black dashed line comes up from the E-DPCCH with the E-TFC.HARQ entity : one per UE, with one stop and wait process per HARQ process ID. Its red dashed line is the ACK/NACK on the E-HICH.De-multiplexing : splits the MAC-e PDU and sends each MAC-es PDU to its MAC-d flow over the Iub, which is the pair of black lines at the top.
Following is the structure of MAC-es. One thing you would notice is that it has many blocks for Reordering. Why do you think we need this kind of reordering ? The answer would be that there are possibility that multiple PDUs from MAC-e may arrive out of sequence ? Then the question is How come those PDUs can arrive out of sequence. It is mainly because the HARQ process in MAC-e. Since multiple HARQ processes can run in paralell, we cannot guarantee that all those data stream coming out of the HARQ process arrive at MAC-es in sequence. So we need some mechanism to realign these incoming PDUs into a proper sequence before passing them to MAC-d. This is the role of Reordering block.
< 25.321 - Figure 4.2.4.4-1 : UTRAN side MAC architecture / MAC-es details(SHO case, FDD) >
From MAC-e in NodeB #1 to NodeB #k : in soft handover, each Node B in the E-DCH active set forwards what it decoded. The crossing lines show that one MAC-d flow can arrive from several Node Bs.Reordering Queue Distribution : one per MAC-d flow. It routes each MAC-es PDU to the reordering queue of its logical channel.Reordering/Combining : one per logical channel. It orders the PDUs by TSN and by the Node B tagging, that is the CFN and subframe. It also handles the copies of one PDU that arrive from two Node Bs, which is the macro diversity selection of 25.321.Disassembly : removes the TSN and hands the MAC-d PDUs to MAC-d.
Following is MAC-i/MAC-is path. For now, just go through the diagram and try to make your own story.
The MAC-i figure below has the same layout as the MAC-e figure. The new block is "Read UE id". The upper label now also says "UL Common MAC flow", because MAC-i also carries CCCH data on a common E-DCH resource in CELL_FACH.
< 25.321 - Figure 4.2.4.8-1 : UTRAN side MAC architecture / MAC-i details(FDD) >
Read UE id : in CELL_FACH, a UE on a common E-DCH resource adds its E-RNTI to the MAC-i header until contention resolution. This block reads it.E-DCH Control and HARQ entity : the same jobs as in MAC-e. The figure labels the signalling only as associated uplink and downlink signalling.De-multiplexing : works on the LCH-ID of the MAC-i header instead of the DDI.
The MAC-is figure below adds one layer to MAC-es. A Reassembly block now sits above Disassembly, because a MAC-i PDU can carry a segment of a MAC-d PDU.
< 25.321 - Figure 4.2.4.7-1 : UTRAN side MAC architecture / MAC-is details for DCCH/DTCH transmission(SHO case, FDD only) >
Reordering and Disassembly : the same jobs as in MAC-es, per logical channel.Reassembly : joins the segments back into complete MAC-d PDUs, using the SS field of the MAC-is header.From MAC-i in NodeB #1 to NodeB #k : the soft handover input is the same as for MAC-es.
It would be more helpful if have the MAC PDU structure, but will come in the following section < Overview on MAC-e/es in UE : HSUPA >. I normally put the PDU structure on transmission side.
MAC-e in the Node B : HARQ, scheduling and de-multiplexing, which are the real time jobs.MAC-es in the SRNC : reordering, macro diversity selection and disassembly.One path per UE : either MAC-e/es or MAC-i/is, never both at the same time.
Overview on MAC-e/es and MAC-i/is in UE : HSUPA
UE side HSUPA block is a little bit simpler than UTRAN side since MAC-e/es are combined in one module. 25.321 says that the split between MAC-e and MAC-es in the UE is not detailed. So the UE figure shows one entity, and the PDU formats are the only place where the two layers are still visible.
For now just try to follow all the possible paths in the following figures.
(When you read this figure, you should be careful about the direction. For the path marked in Black lines, you have to follow from the bottom to the top and for the path marked in red, you should follow from top to the bottom).
For every transmission (TTI), UE MAC-e/es determines the data rate by following criteria
i) Current Serving Grant
ii) Amount of Data waiting to be transmitted
iii) Minimum Allowed Spreading Factor (determined by higher layer signaling)
This sublayer can use multiple HARQs in paralelle and the maximum number of HARQ differs depending on TTI.
i) For 10 ms TTI - 4 HARQs
ii) For 2 ms TTI - 8 HARQs
The HARQ process that transmits in a particular frame is determined from the current CFN (this is unlike HSDPA where each HARQ process transmits in a round-robin fashion).
UE can use chase combining (transmission of the exact same bits again) or incremental redundancy (transmission of a different set of bits) for HARQ retransmission and the RRC layer message determines which method UE has to use.
The figure below shows the UE side entity. Three blocks do the work, and two signalling lines leave the box at the bottom.
< 25.321 - Figure 4.2.3.4-1a : UE side MAC architecture / MAC-e/es details(FDD) >
E-TFC Selection : takes the grants from the E-AGCH and E-RGCH, which are the black dashed line from below. It tells the multiplexing block how much data to take.Multiplexing and TSN setting : builds the MAC-es PDUs from the MAC-d PDUs, sets the TSN per logical channel and builds one MAC-e PDU.Red dashed line on the right : the associated uplink signalling, that is the E-TFC on the E-DPCCH.HARQ : stores the MAC-e PDU for retransmission. The solid red line going down is the E-DCH data. The black dashed line coming up is the ACK/NACK from the E-HICH.
You will get a little bit detailed understanding if you look into the PDU structure as follows.
First PDU is MAC-es PDU. From this structure, you would notice that the main role of MAC-es is to take in multiple MAC-d PDUs and combine them into a single MAC-es PDU.
< 25.321 - Figure 9.1.5-1 : MAC-es PDU >
Meaning of the parameters in the MAC-es PDU is described in the table below.
|
Field |
Field Name |
Bits |
Description |
|
TSN |
Transmission Sequence Number |
6 |
The TSN field provides the transmission sequence number for the MAC-es PDU. This information is used for reordering purposes to support in-sequence delivery to higher layers. |
DDI |
Data description indicator |
6 |
The DDI field identifies the logical channel, MAC-d flow and size of the MAC-d PDUs concatenated into the associated MAC-es PDU. The mapping between the DDI values and the logical channel ID, MAC-d flow and PDU size is provided by higher layers |
N |
Number of MAC-d PDUs |
6 |
The number of consecutive MAC-d PDUs corresponding to the same DDI value. |
Now let's look into MAC-e PDU. From this, you would notice that MAC-e takes in multiple MAC-es PDUs and combine them into a single/big MAC-e PDU. Another thing you should notice is.. MAC-e collect all DDI/N part and connect all of them at the beginning of MAC-e PDU and put all the payload part of MAC-es PDU next to the DDI/N portion.
< 25.321 - Figure 9.1.5-2a : MAC-e PDU >
DDI1 N1 to DDIn Nn : the MAC-e header. There is one pair per MAC-es PDU, so one pair per logical channel in this TTI.DDI0 - Opt : the reserved DDI value 111111. It says that an SI is at the end of the PDU, and no MAC-es PDU belongs to it.MAC-es PDU1 to MAC-es PDUn : the payloads, in the same order as the DDI/N pairs.SI - Opt and Padding - Opt : the 18 bit Scheduling Information and the unused bits of the transport block.
If you want to be able to decode MAC-e PDU completely upto the level of MAC-d SDU level, following illustration would give you better understanding (This come from the combination of Figure 9.1.5-2a, Figure 9.1.5-1 , Figure 9.2.1.1.1)
The illustration stacks three layers. At the top, a MAC SDU from RLC becomes a MAC-d PDU. In the middle, the MAC-d PDUs of one logical channel are joined behind TSN1 into MAC-es PDU1. At the bottom, the MAC-es PDUs and the DDI/N pairs form the MAC-e PDU, as in Figure 9.1.5-2a. The green lines link each layer to the next one.
NOTE : If you tried to decode MAC-e PDU by hands, you would come across an important question. It is, "How do I know the end of MAC-e Header ?".. in other words "How can I know which one is the last DDI ?"
You can find the answer in 25.321-9.2.4.2 MAC-e header parameters, but the short answer is that if you hit [111111] in a DDI field, it means the previous DDI is the last DDI. [111111] is the indicator of end-of-the-header.
Be careful with this short answer, because [111111] is not always there. 25.321 clause 9.2.4.2 defines it as the indicator that a Scheduling Information is concatenated. The UE adds it only when at least 24 bits are left after the data and the header. The next section explains how the header ends when it is absent.
MAC-es adds only a TSN : 6 bits per logical channel per TTI.MAC-e adds only DDI/N pairs : 12 bits per MAC-es PDU, all at the front.One MAC-d PDU size per logical channel per TTI : this is why one DDI can describe the whole MAC-es PDU.
How is a MAC-e PDU decoded step by step ?
The MAC-e header has no length field and no "last" flag. So the receiver must find its end from the transport block size and the DDI table. This works because the UE follows a strict rule about when a DDI field is written.
The rule is in 25.321 clause 9.2.4.2. After the data and the header, the UE looks at the bits left in the transport block. If at least 24 bits are left, it appends DDI0 = 111111 and an 18 bit SI. If 18 to 23 bits are left, it appends only the SI, without DDI0. If fewer bits are left, no DDI is added. So a DDI field always follows while 24 bits or more are free.
From this rule, the decoding steps follow.
Step 1 : read the E-TFCI from the E-DPCCH and find the transport block size in the E-TFCI table of 25.321 Annex B.Step 2 : read 6 bits of DDI. If the value is 111111, the header ends here, and an 18 bit SI follows the last MAC-es PDU.Step 3 : otherwise look up the DDI in the RRC mapping. It gives the logical channel, the MAC-d flow and the MAC-d PDU size.Step 4 : read 6 bits of N, and count the MAC-es PDU as 6 bits of TSN plus N times the MAC-d PDU size.Step 5 : subtract the header bits and the counted payloads from the transport block size. If 24 bits or more remain, go back to Step 2. If not, the header has ended.Step 6 : read the MAC-es PDUs in the order of the DDI/N pairs. If 18 to 23 bits remain at the end, the first 18 of them hold an SI without DDI0. Any other remaining bits are padding.
There is one more case. When an SI is sent alone, the MAC-e PDU holds only the SI, and the E-TFCI is 0. 25.321 Figure 9.1.5-2b shows this format, and it has no DDI0.
In a real log, the DDI mapping comes from the RB mapping info of 25.331 clause 10.3.4.21, in the RRC message that configured the radio bearer. Each logical channel on the E-DCH gets a DDI value from 0 to 62 and a list of RLC PDU sizes. When a channel has several sizes, they use consecutive DDI values from that DDI on. Without that message, a MAC-e PDU cannot be decoded at all.
The transport block size ends the header : DDI0 ends it only when an SI fits in 24 bits or more.The DDI table comes from RRC : keep the Radio Bearer Setup or Reconfiguration next to the MAC log.E-TFCI 0 means SI only : that PDU has no MAC-es payload.
How does MAC-i/is differ from MAC-e/es ?
MAC-e/es has two limits. It can only carry whole MAC-d PDUs of fixed sizes, and it works only in CELL_DCH. Release 8 introduced MAC-i/is to remove both, for flexible RLC PDU sizes and for Enhanced Uplink in CELL_FACH.
The header is the first change. MAC-i describes each MAC-is SDU with its own header fields, so the sizes can differ.
LCH-ID, 4 bits : the logical channel. Value 1110 means CCCH, and 1111 means that the E-RNTI follows, in FDD.L, 11 bits : the length of the MAC-is SDU in octets.F, 1 bit : 0 means another LCH-ID, L and F set follows, and 1 means the header ends. This flag answers the question of the NOTE above directly.
MAC-is adds two fields per MAC-is PDU. The TSN is 6 or 14 bits, depending on the TSN field extension that upper layers configure. The SS field has 2 bits and tells whether the first and the last MAC-is SDU are complete MAC-d PDUs or segments. The Reassembly block in the MAC-is figure uses SS.
In the UE, the Scheduling Information is also handled differently. In CELL_DCH with MAC-i configured, the SI is concatenated whenever the data plus header leaves at least 18 bits in the transport block. No DDI0 exists in MAC-i.
RRC selects MAC-i/is with the field ul-MAC-HeaderType in the E-DCH branch of the UL TrCH information. The tile below shows the current version.
Following is based on
UL-AddReconfTransChInformation-r14 ::= CHOICE {
dch-usch SEQUENCE {
ul-TransportChannelType UL-TrCH-Type,
transportChannelIdentity TransportChannelIdentity,
transportFormatSet TransportFormatSet
},
e-dch SEQUENCE {
ul-MAC-HeaderType ENUMERATED { mac-iis } OPTIONAL,
modeSpecific CHOICE {
fdd SEQUENCE {
tti E-DCH-TTI,
secondaryTTI E-DCH-TTI OPTIONAL
},
tdd NULL
},
harq-Info ENUMERATED { rv0, rvtable },
addReconf-MAC-d-FlowList E-DCH-AddReconf-MAC-d-FlowList-r7 OPTIONAL
}
}
E-DCH-TTI ::= ENUMERATED { tti2, tti10 }
The field has one value, mac-iis. It is OPTIONAL, so a message without it keeps the UE on MAC-e/es. 25.331 also warns that a change between the two header types without the "MAC-es/e reset indicator" leaves the UE behaviour unspecified.
MAC-i has explicit lengths : the F flag marks the last header, so no DDI table is needed to find the end.MAC-is supports segmentation : the SS field tells the receiver how to rebuild a MAC-d PDU.One IE switches the path : ul-MAC-HeaderType present means MAC-i/is, absent means MAC-e/es.
Reference
[1] 3GPP TS 25.321 v19.0.0 - clause 4.2.3.4, 4.2.4.4, 4.2.4.5, 4.2.4.7 and 4.2.4.8, the MAC architecture, and clause 9.1.5 and 9.2.4, the E-DCH MAC PDU formats
[2] 3GPP TS 25.331 v19.0.1 - clause 10.3.5.2, Added or Reconfigured UL TrCH information, and the ASN.1 of clause 11.3