With HSPA carrying all the data, a dedicated channel is still needed for one small job: downlink power control for each UE. F-DPCH does that job with a fraction of a channelisation code instead of a full one.
F-DPCH (Fractional DPCH) is a special type of DPCH channel which can transmit only power control signal.
There has been a lot of advantages of introducing HSPA channel for User data. Everybody would undertand we could achieve much higher data throughput with HSPA comparing to R99 channel. In addition, from Release 6, it was allowed to map SRB onto HSPA channel (Shared Channel). With this, we could make TTI for SRB very short and could exchange signaling message in much timely manner. But there is a drawback of relying on these shared channel method. It is about power control issue. You know that one of the critical requirement of WCDMA technology is a very sophisticated power control. If UE power is too low, Node B would have difficulties decoding it and if the power is too strong It can act as a noise to other UEs communicating with the Node B. For this purpose, Node B sends a UE a power control message periodically and this message should be different for all the UE because each UE may be in a different channel condition, meaning this power control message should be a "Dedicated" message. But as I explained HS-DSCH is a shared channel. Then how can Node B deliver the power control message for each specific UE. The solution was to useR99 dedicated channel (DPCH) carrying only the power control message. But using a full DPCH only for carrying a small power control message is waste of resource. The most important resources that Network would like to save would be 'OVSF (Orthogonal Variable Spreading Factor) Code' which is very limitted. Spreading Factor (SF) for DPCCH is 256 which may seem looks a lot. But since the SF for any HSDPA channel is 16. Any DPCCH spreading code which fall into a HSDPA channelization code may break the whole HSDPA channel.
To improve this situation, from Release 6 a new channel was introduced and it is F-DPCH (Fractional DPCH). The main motivation is to let allocate single channelization code to multiple UEs. In 3GPP spec, it is allowed to allocate a single channelization code to max 10 UEs.
The numbers behind that limit come from the slot. An F-DPCH slot has 20 bits at SF 256, and one UE needs only 2 of them for its TPC command. So 10 UEs can share one code, each using a different 2-bit position. The sections below show the frame structure, the slot formats, and the RRC fields that give each UE its position.
- What does an F-DPCH frame look like ?
- Which slot formats does F-DPCH use ?
- How does the UE report F-DPCH support ?
- How does the network configure F-DPCH ?
- Precondition for F-DPCH
- Reference
What does an F-DPCH frame look like ?
Frame Structure of F_DPCH is as follows. (Refer to 3GPP 25.211 Figure 12B: Frame structure for F-DPCH). As you see, each of the slots carries only TPC bits and the remaining part (originally allocated for user data) is off.
25.211 Figure 12B, frame structure for F-DPCH. Each slot sends only the TPC field and is silent for the rest of the slot.
Bottom : one radio frame of 10 ms with Slot #0 to Slot #14.Top : one slot of Tslot = 2560 chips, split into Tx OFF for NOFF1 bits, TPC for NTPC bits and Tx OFF for NOFF2 bits.No pilot, no TFCI, no data : the UE estimates the channel from the CPICH instead of a dedicated pilot.
Then you may have question. If network allocates a same channelization code to multiple UEs, how a UE can figure out the TPC is for itself or for some other UE. Network uses another indicator for further UE specification and it is Frameoffset. It means even though a Network can allocate a single code to10 different, UE can use detect its own TPC command with using Frameoffset.
Why does a timing offset separate the UEs? 25.211 clause 7.1 puts the start of each F-DPCH frame at a multiple of 256 chips after the P-CCPCH frame, from 0 to 149 steps. At SF 256, 256 chips is exactly one symbol, which carries 2 bits. So shifting the frame offset by one step moves the TPC field by one symbol. A slot holds 10 symbols, and that is where the limit of 10 UEs per code comes from.
One slot, 10 symbols : each UE gets one TPC symbol of 2 bits.Frame offset in 256 chip steps : one step moves the TPC field by one symbol.Same code, different timing : the UEs never transmit TPC at the same time.
Which slot formats does F-DPCH use ?
Following is the slot format for F_DPCH (Refer to 25.211 Table 16C: F-DPCH fields). In Rel 6 when F-DPCH is first introduced, only one slotformat was supported. But in Rel 7 many additional slot formats were introduced.
25.211 Table 16C, F-DPCH fields. All ten slot formats have the same rate and SF, and they differ only in where the 2 TPC bits sit.
Same for every slot format : 3 kbps, 1.5 ksps, SF 256, 20 bits per slot, NTPC = 2.Slot format 0 : NOFF1 = 2 and NOFF2 = 16, the only format in Rel 6.Slot formats 1 to 8 : NOFF1 grows by 2 bits per format, from 4 to 18.Slot format 9 : NOFF1 = 0, so the TPC field starts the slot.Every row : NOFF1 + NTPC + NOFF2 = 20.
Slot formats give the network a second way to separate the UEs. In Rel 6 the network could only shift the frame offset of each UE, which also shifts the frame timing of that UE. In Rel 7 it can keep one frame offset and give each UE a different slot format instead. The table shows 25.211 v19.0.0 and matches the picture, so nothing has changed here since Rel 7. Later releases added only special cases, such as a second F-DPCH for DPCCH2, which must use a different slot format from the first.
Enhanced F-DPCH, Rel 7 : slot formats 1 to 9.Rel 6 UE : slot format 0 only, so frame offset is the only way to separate UEs.Two tools, same result : frame offset and slot format both move the TPC symbol inside the slot.
How does the UE report F-DPCH support ?
The network uses F-DPCH only for a UE that supports it, and enhanced F-DPCH only for a UE that supports the extra slot formats. The UE reports both capabilities already in RRC Connection Request, before any radio bearer exists.
Key Parameters for F_DPCH in RRC message from UE are as follows.
RRC Connection Request. Each F-DPCH capability sits in the non-critical extension of the release that introduced it.
rrcConnectionRequest-v6e0ext : supportForFDPCH, the Rel 6 capability.rrcConnectionRequest-v770ext : mac-ehsSupport true, next to other Rel 7 capabilities.rrcConnectionRequest-v7b0ext : supportForE-FDPCH true, highlighted. This is the capability for slot formats 1 to 9.
Both fields are ENUMERATED { true } and OPTIONAL, so absence means no support. In this capture supportForFDPCH shows no value, and the v6e0 extension shows a bit mask of 0. 25.331 marks Support for F-DPCH with the condition SupportForHS: it is mandatory present when the UE supports HS-PDSCH. This UE reports mac-ehsSupport and supportForE-FDPCH, so the empty field disagrees with that condition. The capture is left as it was recorded.
supportForFDPCH : Rel 6, required from every UE that supports HS-PDSCH.supportForE-FDPCH : Rel 7, the extra slot formats.Absent means not supported : both fields are optional flags.
How does the network configure F-DPCH ?
Now let's look at the other direction. The network configures F-DPCH in two parts: one part common to all radio links, and one part for each radio link. The picture right below shows the common part, and the part for one radio link follows it.
Key Parameters for F_DPCH in RRC message (Usually in Radio Bearer Setup) from Network are as follows.
dl-FDPCH-InfoCommon. The DPC mode and the TPC command error rate target apply to all radio links.
cfnHandling : maintain, so the UE keeps its CFN.dpc-Mode : singleTPC, with tpcTripletInSoft as the other choice.dl-FDPCH-TPCcommandErrorRate : 4, which is a target of 0.04.
The part for one radio link is shown below. It holds the fields that place this UE on a shared code.
dl-FDPCH-InfoPerRL. Frame offset, slot format and code number together give the UE its TPC position on a shared code.
pCPICH-UsageForChannelEst : mayBeUsed.fdpch-FrameOffset : 0, range 0 to 149 in steps of 256 chips.fdpch-SlotFormat : 0, range 0 to 9.dl-ChannelisationCode : 10, range 0 to 255 at SF 256.tpc-CombinationIndex : 0, range 0 to 5.
The DPC mode tells the UE how to send its uplink TPC commands, which control the power of the F-DPCH itself. With singleTPC, DPC_MODE 0 in 25.214, the UE sends a new command in every slot. With tpcTripletInSoft, DPC_MODE 1, the UE repeats one command over 3 slots. The TPC command error rate replaces the usual outer loop. An F-DPCH carries no transport block, so the UE cannot measure a BLER on it. Instead the UE adjusts its own SIR target until the TPC commands from the HS-DSCH serving cell reach this error rate target.
The tile below gives the two IEs from the current 25.331. In the tabular description, F-DPCH frame offset is 0 to 38144 chips in steps of 256, which is the same range as the ASN.1 value 0 to 149. The slot format is optional, and its absence means slot format 0. Radio links with the same TPC combination index form one radio link set, so the UE combines their TPC commands in soft handover.
Following is based on
DL-FDPCH-InfoCommon-r6 ::= SEQUENCE {
cfnHandling CHOICE {
maintain SEQUENCE {
timingmaintainedsynchind TimingMaintainedSynchInd OPTIONAL
},
initialise NULL
},
dl-FDPCH-PowerControlInfo DL-DPCH-PowerControlInfo OPTIONAL,
-- Actual value dl-FDPCH-TPCcommandErrorRate = IE value * 0.01
-- dl-FDPCH-TPCcommandErrorRate values 11..16 are spare and shall not be used in this version of
-- the protocol.
-- In addition, this IE shall always be included otherwise the UE behaviour is unspecified.
dl-FDPCH-TPCcommandErrorRate INTEGER (1..16) OPTIONAL
}
DL-DPCH-PowerControlInfo ::= SEQUENCE {
modeSpecificInfo CHOICE {
fdd SEQUENCE {
dpc-Mode DPC-Mode
},
tdd SEQUENCE {
tpc-StepSizeTDD TPC-StepSizeTDD OPTIONAL
}
}
}
DPC-Mode ::= ENUMERATED {
singleTPC,
tpcTripletInSoft }
DL-FDPCH-InfoPerRL-r7 ::= SEQUENCE {
pCPICH-UsageForChannelEst PCPICH-UsageForChannelEst,
fdpch-FrameOffset DPCH-FrameOffset,
fdpch-SlotFormat FDPCH-SlotFormat OPTIONAL,
secondaryCPICH-Info SecondaryCPICH-Info OPTIONAL,
secondaryScramblingCode SecondaryScramblingCode OPTIONAL,
dl-ChannelisationCode INTEGER (0..255),
tpc-CombinationIndex TPC-CombinationIndex,
sttdIndication STTDIndication OPTIONAL
}
DPCH-FrameOffset ::= INTEGER (0..149)
FDPCH-SlotFormat ::= INTEGER (0..9)
TPC-CombinationIndex ::= INTEGER (0..5)
Common part : DPC mode and the TPC command error rate target, 0.01 to 0.1.Per radio link part : frame offset, slot format, code number and TPC combination index.No BLER on F-DPCH : the TPC command error rate is the quality target.
Precondition for F-DPCH
Followings are the list of preconditions for F-DPCH. Enabling F-DPCH means disabling ordinary DPDCH channel, you may easily understand why following precondition should be met.
- HSDPA should be enabled
- HSUPA should be enabled
- SRB should be mapped onto HSPA
The list follows from what F-DPCH removes. There is no downlink DPDCH, so every downlink logical channel, including the SRBs, must be mapped to HS-DSCH. In the uplink, the UE still sends a DPCCH, which carries the pilot and the TPC commands for the downlink. The list above also asks for HSUPA, so the uplink SRBs and data are carried on E-DCH in that configuration.
No downlink DPDCH : HS-DSCH carries all downlink data and signalling.CS voice : a DCH based call needs a DPCH again, unless the UE supports CS voice over HSPA.Uplink DPCCH stays : it carries the uplink pilot and the TPC commands for the F-DPCH.UE capability first : the network checks supportForFDPCH and supportForE-FDPCH before it configures the channel.
The preconditions also explain what happens when a CS voice call starts. A conventional CS call is carried on a DCH, which needs a downlink DPDCH. So the network normally reconfigures the UE from F-DPCH back to a DPCH for the call. A UE that supports CS voice over HSPA, reported as supportForCSVoiceoverHSPA in the v7e0 extension of RRC Connection Request, can instead keep the voice on HSPA and stay on F-DPCH.
Reference
[1] 3GPP TS 25.211 v19.0.0 - clause 5.3.2.6, Figure 12B and Table 16C, and clause 7.1 for the F-DPCH timing
[2] 3GPP TS 25.214 - clause 5.2.1.2, DPC_MODE and the F-DPCH quality target
[3] 3GPP TS 25.331 v19.0.1 - clauses 10.3.6.23oa and 10.3.6.23ob, and the ASN.1 of DL-FDPCH-InfoCommon-r6 and DL-FDPCH-InfoPerRL-r7