CPC (Continous Packet Connectivity)

A smartphone rarely sends data continuously. It sends a burst, stays silent while the user reads, and then sends another burst. CPC is the Release 7 set of features that lets such a UE stay in CELL_DCH through the silent gaps without wasting battery and uplink capacity. I'll start with the problem, and then go through each CPC feature: UL DTX, DL DRX, HS-SCCH orders, HS-SCCH-less operation and the RRC configuration that enables them.

Why does a packet data user need CPC ?

Let's start with the traffic pattern, because CPC exists only because of it. The network can move an idle UE between RRC states, but every state change costs signalling and delay. CPC takes a different approach and makes the connected state itself cheaper.

Let's suppose a situation, say Web browsing for example. While you are reading a page, you are not downloading any data and there are no data communication between UE and the network. During this time, usually RRC state is put into Cell_FACH and Cell_PCH. When you finish reading the page and try to go next page, in this case the RRC state should change back into Cell_DCH.

The state change described above is one way to handle the idle time, and it costs signalling and delay every time the user clicks.

Another way to improve the problem related to RRC State changes would be to increase the data rate at Cell_FACH. Theoretically you can transmit the data in Cell_FACH in previous technology and ideally the throughput is around 34 K. But if you really try it, you may notice the real throughput is much less than this. For HSPA+, the throuhgput for Cell_FACH has been much increased by Enhanced Cell_FACH.

To save battery consumption, UE can repeat very short cycles of 'sleeping mode' and 'wake up' mode when there is no data traffic and normally this repetition cycles is much shorter than DCH<--> FACH <--> PCH cycles. This kind of 'sleeping' and 'wake up' cycles are called DTX, DRX.

If you apply all these techniquest described above in wise combination, you would achieve such a status as

i) Users feels like they are continuously connected to the network (User experience very short latency as if it is always connected).

ii) Even with this kind of user experience, energy consumption (current consumption) on UE can be minimized

All the combination of this technique to achieve such a user experience is called "CPC". It means CPC is a collective terminoloty for a set of technologies, not any specific single technology. It implies that to understand CPC requires a lot of efforts -:)

Just in short, CPC is a combined technology of all of the following features.

UL-DTX
DL-DRX
HS-SCCH orders
HS-SCCH-less
New UL-DPCCH slot format #4
Cell DCH using E-DCH/HS-DSCH
SRBs mapped on E-DCH/HS-DSCH with use of F-DPCH

The last two items in the list are preconditions rather than savings. CPC applies only to an FDD UE in CELL_DCH that has F-DPCH configured and no DCH in either direction. So the signalling radio bearers must run on HS-DSCH in the downlink and on E-DCH in the uplink. A UE that still carries a DCH cannot use UL DTX, DL DRX or HS-SCCH-less operation.

The reason for all this is uplink capacity as much as battery life. In Release 6, a UE in CELL_DCH sends the uplink DPCCH in every slot, even when it has no data. Every such UE adds noise at the Node B receiver, so a cell can keep only a limited number of idle users in CELL_DCH. The CPC work item set two targets: many more packet users in CELL_DCH, and a restart after inactivity in less than 50 ms. CPC is mandatory for Release 7 and later FDD UEs that support HSDPA and E-DCH, but the RNC enables it for each UE separately.

CPC keeps the UE in CELL_DCH : it reduces the cost of staying connected instead of moving the UE to CELL_FACH or CELL_PCH.
CPC needs F-DPCH and no DCH : the SRBs have to be mapped on HS-DSCH and E-DCH before any CPC feature can be configured.
The main saving is uplink noise : fewer DPCCH slots from idle UEs leave more uplink capacity for the UEs that have data.

How does UL DTX reduce the uplink DPCCH ?

UL DTX is the core of CPC, and the other features build on it. The question it answers is simple: how often must an idle UE send the uplink DPCCH so that the Node B keeps synchronisation and power control? The answer depends on how long the UE has been inactive.

The UE sends the DPCCH whenever it sends E-DCH or HS-DPCCH. When both are silent, the UE sends only a short DPCCH burst of UE_DPCCH_burst_1 subframes once every UE_DTX_cycle_1 subframes. If the UE has sent no E-DCH for Inactivity_Threshold_for_UE_DTX_cycle_2 E-DCH TTIs, it moves to the longer pattern. Then it sends UE_DPCCH_burst_2 subframes once every UE_DTX_cycle_2 subframes. UE_DTX_DRX_Offset shifts the pattern, so different UEs send their bursts at different times.

The timeline below shows the two patterns after a period of E-DCH activity. The dark blocks are DPCCH transmissions, and the gaps between them are DTX.

Figure 1. Uplink DPCCH burst pattern with UL DTX. The longer the E-DCH inactivity, the fewer DPCCH slots the UE sends, and the less noise it adds at the Node B.

The block on the left is continuous DPCCH. It lasts as long as the UE sends E-DCH or HS-DPCCH.
Pattern 1 applies right after the activity. The bursts are short and frequent, so the UE can restart quickly.
The dashed line marks Inactivity_Threshold_for_UE_DTX_cycle_2, counted in E-DCH TTIs without an E-DCH transmission.
Pattern 2 uses the longer UE_DTX_cycle_2. The bursts are drawn wider only to show that UE_DPCCH_burst_2 is configured separately from UE_DPCCH_burst_1.

Each burst needs some extra slots around it. Before a DPCCH burst, the UE sends a 2 slot preamble, and after it, a 1 slot postamble. The UE also restarts E-DCH carefully after a long silence. After Inactivity_Threshold_for_UE_DTX_cycle_2 TTIs without E-DCH, it sends a long preamble of UE_DTX_long_preamble_length slots, up to 15 slots, before the E-DCH TTI. The CQI on HS-DPCCH also follows the pattern: the UE sends a CQI only where its reporting period overlaps a DPCCH transmission. CQI_DTX_TIMER gives CQI priority over the DTX pattern for some subframes after an HS-DSCH reception.

Uplink DRX is an optional addition to UL DTX. After UE_Inactivity_Threshold TTIs without E-DCH, the UE may start a new E-DCH transmission only at the times given by MAC_DTX_cycle. This lets the Node B receiver sleep as well. The RNC cannot configure uplink DRX without UL DTX.

The new UL DPCCH slot format #4 belongs to the same package. In 25.211 Table 2, slot format #4 has 6 pilot bits and 4 TPC bits, with no TFCI and no FBI field. The extra TPC bits make power control more reliable, so the UE can send the DPCCH at a lower power. The RNC can use slot format #4 only together with UL DTX.

UL DTX adapts by itself : the UE moves from UE_DTX_cycle_1 to UE_DTX_cycle_2 by a standard rule, without any signalling.
Data always wins over DTX : the DPCCH is continuous whenever E-DCH or HS-DPCCH is transmitted.
Every burst carries a preamble and a postamble : so a DPCCH burst of one subframe occupies six slots on air.

How does DL DRX limit the downlink reception ?

UL DTX saves uplink power, but the UE receiver still runs all the time. DL DRX answers the next question: when must the UE listen to the downlink? The answer is a fixed HS-SCCH reception pattern, plus a list of events that force the UE to listen.

The RNC configures UE_DRX_cycle in subframes. The UE must receive one HS-SCCH subframe every UE_DRX_cycle subframes, and UE_DTX_DRX_Offset shifts this pattern per UE. In 25.331, UE-DRX-Cycle takes the values 4, 5, 8, 10, 16 and 20 subframes. Enhanced DRX adds a second cycle, UE_DRX_cycle_2, which the UE uses after Inactivity_Threshold_for_UE_DRX_cycle_2 subframes without HS-SCCH reception.

Outside the pattern, the UE does not need to receive the downlink physical channels. But several events override this rule. The UE must receive the E-HICH for its own E-DCH transmission. It must receive the HS-PDSCH after a correctly received HS-SCCH. It must also listen continuously for Inactivity_Threshold_for_UE_DRX_cycle subframes after an HS-SCCH or HS-PDSCH reception. Finally, when UE_DRX_Grant_Monitoring is TRUE, it monitors the grant channels while it has scheduled E-DCH data to send.

Two limits keep DL DRX safe. First, the RNC cannot configure DL DRX without UL DTX. Second, DRX never blocks mobility, since the UE cannot use DRX when it has to perform measurements. Note also that DRX is a permission, not an obligation. A UE may keep receiving continuously, and switching off the receiver remains a UE implementation choice.

The HS-SCCH pattern is the anchor : the Node B schedules a DRX UE only in the subframes where the UE is sure to listen.
Activity stops DRX : any HS-SCCH or HS-PDSCH reception restarts the inactivity threshold and keeps the receiver on.
DL DRX depends on UL DTX : the reverse is not true, so a UE can run UL DTX with continuous downlink reception.

What do HS-SCCH orders and HS-SCCH-less operation add ?

RRC signalling is too slow to switch DTX and DRX on and off with every traffic burst. CPC therefore gives the Node B a layer 1 switch, the HS-SCCH order. HS-SCCH-less operation then removes the HS-SCCH for small first transmissions, which matters for VoIP.

An HS-SCCH order is an HS-SCCH that carries a command instead of a downlink assignment. With it, the serving Node B can deactivate or activate UL DTX, DL DRX and HS-SCCH-less operation. The timing is defined in 25.214 subclause 6C.4. A DRX order takes effect 12 slots after the end of the HS-SCCH subframe that delivered it. A DTX order takes effect at the first E-DCH TTI boundary at or after the start of the HS-DPCCH subframe that carries its HARQ-ACK. So the UE acknowledges an order on HS-DPCCH just as it acknowledges data.

HS-SCCH-less operation sends the first transmission of a small transport block on HS-PDSCH without any HS-SCCH. Because nothing announces it, the UE decodes it blindly. Several limits keep that blind decoding affordable:

The modulation is QPSK only.
Only 4 predefined transport block formats are allowed, and the RNC chooses them for each UE.
At most two predefined HS-PDSCH OVSF codes are assigned to the UE.
The HS-PDSCH carries a 24 bit CRC masked with the 16 bit H-RNTI, so the UE can recognise its own data.
The UE keeps a soft buffer of 13 TTIs, and it sends no NACK after a failed first transmission.
Up to 2 retransmissions follow, each with an HS-SCCH that points back to the TTI of the first transmission.

The trade-off is easy to see. A VoIP frame is small and periodic, so an HS-SCCH for every frame costs almost as much as the data. HS-SCCH-less operation removes that overhead for the transmissions that succeed first time. It uses the HS-SCCH only for the retransmissions.

HS-SCCH orders are fast control : a DRX order takes effect 12 slots after its HS-SCCH subframe, which is much faster than any RRC reconfiguration.
HS-SCCH-less is for small packets : QPSK, four formats and two codes limit it to VoIP-sized transport blocks.
No NACK on the first transmission : the Node B learns about a failure only from a missing ACK.

How does RRC configure CPC ?

The RNC decides which CPC features each UE uses, and RRC carries that decision. Let's look at the IEs, because a CPC problem in a log usually starts with a wrong or missing value here. The Node B gets the same parameters from the RNC over NBAP.

The IE dtx-drx-Info carries the DTX and DRX parameters, and dtx-drx-TimingInfo tells the UE when to start them. Both are optional IEs in messages such as RRCConnectionSetup, RadioBearerSetup, RadioBearerReconfiguration, TransportChannelReconfiguration, PhysicalChannelReconfiguration, CellUpdateConfirm and ActiveSetUpdate. The ASN.1 below shows the Release 7 structure.

Following is based on 25.331 v19.0.1 (Release 19)

DTX-DRX-Info-r7 ::=					SEQUENCE {
	dtx-Info							DTX-Info							OPTIONAL,
	drx-Info							DRX-Info							OPTIONAL,
	uplink-DPCCHSlotFormatInformation	Uplink-DPCCH-Slot-Format-Information
}

DTX-Info ::=						SEQUENCE {
	e-dch-TTI-Length					CHOICE {
		dtx-e-dch-TTI-10ms					DTX-E-DCH-TTI-10ms,
		dtx-e-dch-TTI-2ms					DTX-E-DCH-TTI-2ms
	},
	ue-dtx-cycle2InactivityThreshold	UE-DTX-Cycle2InactivityThreshold,
	ue-dtx-cycle2DefaultSG				INTEGER (0..38)						OPTIONAL,
	-- if ue-dtx-long-preamble-length is not present, the value is '2 slots'
	ue-dtx-long-preamble-length			UE-DTX-long-preamble-length			OPTIONAL,
	mac-InactivityThreshold				MAC-InactivityThreshold,
	cqi-dtx-Timer						CQI-DTX-Timer,
	ue-dpcch-Burst1						UE-DPCCH-Burst,
	ue-dpcch-Burst2						UE-DPCCH-Burst
}

DRX-Info ::=						SEQUENCE {
	ue-drx-Cycle						UE-DRX-Cycle,
	ue-drx-Cycle-InactivityThreshold	UE-DRX-Cycle-InactivityThreshold,
	ue-GrantMonitoring-InactivityThreshold
										UE-GrantMonitoring-InactivityThreshold,
	ue-drx-GrantMonitoring				BOOLEAN
}

DTX-DRX-TimingInfo-r7 ::=			SEQUENCE {
	timing								CHOICE {
		continue							NULL,
		newTiming							NewTiming
	}
}

NewTiming ::=						SEQUENCE {
	enablingDelay						EnablingDelay,
	ue-dtx-drx-Offset					UE-DTX-DRX-Offset
}

A few fields need a short note. The e-dch-TTI-Length choice selects one of two sets of cycle values, one for the 10 ms E-DCH TTI and one for the 2 ms TTI. The two burst fields take 1, 2 or 5 subframes. If ue-dtx-long-preamble-length is absent, the long preamble is 2 slots, which is the same as the default preamble. The field uplink-DPCCHSlotFormatInformation is where slot format #4 is selected.

The enablingDelay in NewTiming is counted in radio frames, from 0 to 128. During this delay, the UE and the Node B transmit continuously, so synchronisation and power control can settle. DTX and DRX start only after it. The HS-SCCH-less parameters travel in a separate IE, hs-scch-LessInfo, in the same messages. From Release 12, some messages carry DTX-DRX-Info-r12 instead, which adds the second DRX cycle and DTX on a secondary uplink frequency.

Two IEs work together : dtx-drx-Info holds the parameters, and dtx-drx-TimingInfo with enablingDelay and ue-dtx-drx-Offset holds the timing.
Check enablingDelay first : a UE transmits continuously until it expires, which can look like CPC is not working.
The same values go to the Node B : UE and Node B must use the same pattern, or the Node B listens in the wrong subframes.

Reference

3GPP TS 25.308 v19.0.0 - clause 11 Discontinuous UL DPCCH transmission and discontinuous reception, clause 12 HS-SCCH-less HS-DSCH transmission
3GPP TS 25.214 v19.0.0 - clause 6C Discontinuous transmission and reception procedures
3GPP TS 25.211 v19.0.0 - Table 2 DPCCH fields
3GPP TS 25.331 v19.0.1 - DTX-DRX-Info-r7, DTX-Info, DRX-Info, DTX-DRX-TimingInfo-r7, UE-DRX-Cycle, EnablingDelay
3GPP TR 25.903 v19.0.0 - clause 5.1 Overview of the selected solution