Continuous Packet Connectivity There are several posts written on Continuous Packet Connectivity but many of them focus on the big picture of why that feature has been introduced. Whilst the big picture is very important I felt a need for more detailed explanation of what this feature is, and hence this post and the following posts related to this subject. Motivation: With the introduction of high speed packet channels in Rel-5 and Rel-6 of UMTS significantly higher throughput, in the order of several Mbps, can be (or has been) achieved in the downlink and uplink respectively. However, one of the drawbacks of this scheme is that control channels need to be transmitted continuously both in the uplink and the downlink. The continuous transmission of uplink control channel (U-DPCCH) will result in high noise in the cell and thus reducing the capacity of the cell. It will also lead to higher battery power consumption. Similarly, the continuous reception of downlink control channel (HS-SCCH) will also lead to higher battery power consumption in the mobile. This will result in end-user experiencing less talk time on his/her mobile and may also not be able to make voice calls or browse internet because of too much noise in the cell. The only way an end-user may perceive noise in the cell is when they are unable to make calls in spite of dialling the numbers or when the browser could not load/refresh the data. To address these 3GPP has defined a new feature called Continuous Packet Connectivity in Rel-7. This new feature will address the above shortcomings, improve the system capacity for services like VoIP amongst others, reduces the air interface (Uu) latency by employing L1 signalling, and gives an improved power control mechanism. Continuous Packet Connectivity, shortly referred to as CPC, is a collection of the following features:

• Discontinuous Transmission (UL-DTX) – to reduce the cell interference for increasing the system capacity and also to save battery power consumption

• Discontinuous Reception (DL-DRX) – to save battery power consumption HS-SCCH Less Mode – to improve the system capacity for services like VoIP amongst others

• HS-SCCH Orders – to reduce the latency of air interface signalling by using fast L1 signalling mechanism

• New slot format in U-DPCCH – to improve the power control of the downlink

The details of the above features are going to be given in future posts.

1. Continuous Packet Connectivity - Discontinuous Reception (DL-DRX)

As I have written in my earlier posts (CPC), discontinuous reception, shortly called as DL-DRX, is one of the features in CPC. DL-DRX will enable the mobile to receive the control channel (HS-SCCH) in the downlink as per certain defined rules instead of listening continuously and thus saving battery power consumption. This is particularly helpful if the nature of data that is downloaded by the user is periodic or in short bursts, in the sense the mobile need not receive the control channel in the downlink during periods of inactivity. The end-user may experience the benefit of this feature in terms of higher battery life or longer talk time even though they browse or access the internet constantly. To understand this feature in depth one need to understand the following parameters:

• UE_DRX_Cycle – defines the pattern in which HS-SCCH is to be received. It is defined in subframes. • Inactivity_Threshold_For_UE_DRX_Cycle – defines the number of subframes for which HS-SCCH is

continuously listened to by the UE after the HS-SCCH is received as per the UE_DRX_Cycle pattern or after receiving the 1st slot of HS-PDSCH in the case of HS-SCCH less mode transmission. From here on this parameter is also shortly referred as inactivity timer.

The above two parameters are even better explained using an illustration.

In the above diagram DL-DRX is activated at CFN 30. It is only after EnablingDelay frames the DL-DRX is actually activated i.e. DL-DRX is actually activated at CFN 31 (refer to my earlier posts for the EnablingDelay). Once DL-DRX is activated Node-B will transmit HS-SCCH in a CFN and a subframe only when the following condition holds true: ((5 x CFN – UE_DTX_DRX_Offset + Subframe) mod UE_DRX_Cycle = 0 In the above diagram this equation holds true at (31, 1) and hence Node-B has transmitted HS-SCCH. After the transmission at (31, 1) the inactivity timer starts from the beginning of (31, 2). Since the inactivity timer is defined as 8 subframes UE will continuously listen to HS-SCCH from (31, 2) to (32, 4) and hence Node-B can also schedule downlink transmission anywhere between (31, 2) and (32, 4) inclusive. If Node-B schedules any downlink transmission while the inactivity timer is running then the inactivity timer is restarted in the subsequent frame of HS-SCCH transmission. In this example, when the inactivity timer is running between (31, 2) and (32, 4) Node-B scheduled downlink transmission at 32, 0) and hence inactivity timer restarted at (32, 1). After the timer is restarted at (32, 1) Node-B scheduled downlink transmission at (32, 2) and hence the timer is restarted at (32, 3). Once the timer is restarted at (32, 3) there is no downlink transmission until the timer expired at (34, 1). After this point, the Node-B should only schedule downlink transmission only at certain (CFN, subframe) for which the above given formula holds true. This formula holds true at (34, 2), (35, 1) and (36, 0) and therefore they are marked as positions at which Node-B can schedule downlink transmission or UE will listen to HS-SCCH. After the downlink transmission at (36, 4) the timer is restarted. That means Node-B can schedule downlink transmission at any frame starting from (37, 0) and up to (38, 2). After the timer expiry at (38, 2) Node-B can schedule downlink transmission at the DL-DRX positions which are marked with splashes.

In addition to the rules defined above for UE to listen to HS-SCCH and HS-PDSCH the UE will have to follow certain other rules to listen to E-HICH, E-AGCH and E-RGCH. Interested readers can refer to section 6C.1 of TS 25.214 and section 11.8.1.8 of 25.321.

2. Continuous Packet Connectivity - Discontinuous Transmission (UL-DTX)

UL-DTX, referred as discontinuous transmission in the uplink, enables the UE to transmit discontinuously on the U-DPCCH physical channel during the periods of inactivity in data transmission; this is also called as U-DPCCH gating. With the help of UL-DTX, the U-DPCCH can be transmitted in certain patterns/cycles during the periods of inactivity resulting in saving power consumption in the UE and reducing the overall cell interference thereby increasing the capacity in the cell. In UL-DTX mode, UE shall not transmit U-DPCCH when:

• There is no transmission on HS-DPCCH for transmitting ACK/NACK/DTX • There is no transmission on HS-DPCCH for transmitting CQI report • There is no E-DCH transmission

When UL-DTX mode is activated and when the above conditions hold true, UE shall make periodic and short U-DPCCH transmission, also called as DPCCH burst, once every UE_DTX_cycle_1 subframes. If this period of inactivity continues for Inactivity_Threshold_for_UE_DTX_cycle_2 consecutive E-DCH TTIs since the last E-DCH transmission then UE shall transmit U-DPCCH burst once every UE_DTX_cycle_2 subframes. This concept is better explained with an illustration but before going into an illustration one needs to understand the following parameters:

• Enabling _Delay – U-DPCCH and the F-DPCH is transmitted continuously for Enabling_Delay radio frames before UL-DTX is activated. This will enable UE and the network to be in sync before moving to UL-DTX mode.

• UE_DTX_DRX_Offset – This will enable the network to offset the UL-DTX (or DL-DRX) by that many number of subframes. Networks will use this parameter to easily identify the UL-DTX patterns of different UEs by assigning each UE a different offset.

• U-DPCCH Preamble – Few slots of U-DPCCH transmission before the actual U-DPCCH transmission. This is typically for 2 slots. Premable, together with postamble is used for improved channel estimation and better power control.

• U-DPCCH Postamble – Few slots of U-DPCCH transmission after the actual U-DPCCH transmission. This is typically for 1 slot.

• UE_DPCCH_burst_1 – U-DPCCH transmission in subframes during UE_DTX_cycle_1

• UE_DPCCH_burst_2 – U-DPCCH transmission in subframes during UE_DTX_cycle_2

UL-DTX cycles and inactivity timer

As illustrated in the figure above, UL-DTX is activated at CFN 60 but the actual discontinuous transmission will start from CFN 61 i.e. after Enabling_Delay number of frames. This is to enable UE and the network to establish and maintain synchronisation, especially in cases where there was no previously established dedicated radio link. For example, scenarios like connection establishment from IDLE state to CELL_DCH RRC state, or when transitioning from CELL_FACH to CELL_DCH RRC state. After Enabling_Delay radio frames, transmission on U-DPCCH would occur at a CFN and a subframe that satisfies the following formula: (5*CFN – UE_DTX_DRX_Offset + Subframe) mod UE_DTX_cycle_1 = 0 At (61, 3) UE is transmitting 1 subframe of U-DPCCH burst transmission because the above formula holds true at (61, 3). This U-DPCCH burst transmission is also preceded and followed by U-DPCCH preamble and postamble of 2 slots and 1 slot respectively. After the first DTX transmission the subsequent transmission would occur at (62, 2) i.e. after UE_DTX_cycle_1 (4) subframes. UE will continue to transmit in UE_DTX_cycle_1 until the Inactivity_Threshold_for_UE_DTX_cycle_2 timer expires. The timer is started as soon as UL-DTX is activated i.e. after Enabling_Delay radio frames. When the timer expires then UE will move from a shorter cycle (UE_DTX_cycle_1) to a longer cycle (UE_DTX_cycle_2). In the diagram, inactivity timer expired at (62, 3). Therefore, UE will make the next transmission at (64, 0) instead of at (63, 1). When the UE moves from UE_DTX_cycle_1 to UE_DTX_cycle_2 the transmission on the U-DPCCH should hold the following formula: (5*CFN – UE_DTX_DRX_Offset + Subframe) mod UE_DTX_cycle_2 = 0 Because of E-DCH transmission at (65, 3), UE will move back to UE_DTX_cycle_1 from UE_DTX_cycle_2 and continues to be UE_DTX_cycle_1 in until the inactivity timer expires. While the UE is in UL-DTX mode any new E-DCH transmission should coincide with the beginning of either UE_DTX_cycle_1 or UE_DTX_cycle_2. But for immediately subsequent E-DCH transmissions the above formulae need not hold true. That is why at (69, 0) and (69, 1) there is an E-DCH transmission.

DTX cycles with U-DPCCH burst transmission of more than 1 subframe

The above illustration shows the same concept but with different values for UE_DPCCH_burst_1 and UE_DPCCH_burst_2. In practise it will be highly unusual to use any value other than 1 subframe for UE_DPCCH_burst_1 and UE_DPCCH_burst_2 because the purpose of reducing the transmission on UL would be defeated if lengthier transmissions were to be made during periods of inactivity. Having said that, higher values for UE_DPCCH_burst_1 and UE_DPCCH_burst_2 could be used in bad radio conditions for better synchronisation purposes. Affect of HS-DPCCH transmission on DTX cycles

The following are illustrated in the illustration given above: When there is an HS-DPCCH transmission in UE_DTX_cycle_2 then UE would continue to operate in UE_DTX_cycle_2 instead of moving to UE_DTX_cycle_1. In the figure above, (64, 0) there is an HS-DPCCH transmission but UE did not move back to UE_DTX_cycle_1 and continued to operate in UE_DTX_cycle_2. Therefore, the next transmission is at (65, 3) i.e. coinciding with UE_DTX_cycle_2 instead of at (64, 4). Note that, in comparison, E-DCH transmission coinciding with UE_DTX_cycle_2 will result in UE moving back

from UE_DTX_cycle_2 to UE_DTX_cycle_1. Therefore, after an E-DCH transmission at (65, 3) the next U-DPCCH burst is at (66, 2). During an E-DCH transmission in UE_DTX_cycle_2, UE would use long preamble (formally referred as UE_DTX_Long_Preamble_Length) immediately prior to E-DCH transmission. In the above illustration, before the E-DCH transmission at (65, 3) long preamble of 4 slots is transmitted in U-DPCCH prior to U-DPCCH transmission at (65, 3). DTX cycles and inactivity timer with 10 ms E-DCH TTI

In the above figure the UE_DTX_cycle_1, UE_DTX_cycle_2 and the Inactivity_Threshold_for_UE_DTX_cycle_2 are illustrated with a 10 ms E-DCH TTI. The inactivity timer initially started at (62, 0) expires after (65, 4) i.e. after 40 ms or 4 E-DCH TTIs. During an E-DCH transmission i.e. at CFN 68 and CFN 70 U-DPCCH is transmitted for the entire transmission of its corresponding E-DCH. UL-DRX

The network can optionally configure the UE to send E-DCH transmission on the uplink following a cycle (MAC_DTX_cycle) if there has been inactivity for a certain period of time (MAC_Inactivity_Threshold). But if there is an E-DCH transmission at any point then the inactivity timer is reset. This feature allows the Node-B to save resources because it does not need to listen to each TTI for reception of E-DCH data after a certain period of inactivity.

In the figure above the concept is illustrated. If there is an E-DCH transmission at (62, 3) then MAC_Inactivity_Threshold timer is (re)started. When the timer expires at (65, 3) the UE can schedule E-DCH transmission only in if the following formula holds true: For 2ms TTI: (5*CFN – UE_DTX_DRX_Offset + Subframe) mod MAC_DTX_cycle = 0 For 10ms TTI: (5*CFN – UE_DTX_DRX_Offset) mod MAC_DTX_cycle = 0 Because the above formula holds true UE scheduled an E-DCH transmission at (67, 1). The inactivity timer is restarted after the transmission at (67, 1) i.e. MAC can schedule E-DCH data in any TTI until the timer expires. Therefore MAC has scheduled the next E-DCH transmission at (67, 2), likewise at (67, 3). When UL-DTX and UL-DRX are configured together, as illustrated in the above figure, after the expiry of MAC_Inactivity_Threshold timer UE should also need to take into account that a scheduled E-DCH transmission satisfies the formulae for UL-DTX cycles and MAC_DTX_cycle. Therefore, the transmission at (67, 1) also coincides with the UE_DTX_cycle_2. Similarly, even when the MAC_Inactivity_Threshold timer is running, the E-DCH transmission should also coincide with the UE_DTX_cycle_1/UE_DTX_cycle_2. Therefore E-DCH transmission at (70, 2) coincides with the UE-DTX cycle. To consider the above two points, the configured value of MAC_DTX_cycle should be an integer multiple/divisor of UE_DTX_cycle_1. I hope the above explanation on discontinuous transmission is helpful. Remaining features of CPC shall be explained in detail in later posts. References: TS 25.999, TS 25.331, TS 25.214 & TS 25.321

3. Continuous Packet Connectivity - HS-SCCH Less Mode

This is a continuation of explanation of the features in CPC (see my earlier post for a general description on CPC). The transmission in the downlink on the HSDPA channels involves transmitting the control information essential for decoding the data. The control information is transmitted on HS-SCCH (High Speed Shared Control Channel) and the data is transmitted on up to 15 HS-PDSCH (High Speed Physical Downlink Shared Channel). The decoding of data on HS-PDSCH channels is communicated by the UE to the network on HS-DPCCH channel in the uplink. Typical transmission using HS-SCCH, HS-PDSCH and HS-DPCCH is illustrated below:

The control information on HS-SCCH mainly consists of following for correctly demodulating and decoding the data:

• Modulation Scheme • Number of Channelisation Codes • Transport Block Size • HARQ Identifier • Redundancy and Constellation Version • New Data Indicator • UE Specific CRC

Modulation Scheme and the number of channelisation codes form part 1 of the control information and it is used by the UE to demodulate the signal. Once the signal is demodulated the remaining bits of the control information is used by the UE to decode the data. Since the HSDPA channels are shared by several UEs the network should indicate which UE the data is meant for. It will do that by coding the CRC with a UE specific identifier called H-RNTI, which is signalled by the network to the UE in a RRC signalling message.

To summarise, data transmission on HS-PDSCH channels entail transmitting control information on HS-SCCH i.e. in one sense HS-SCCH is an overhead for transmitting certain types of traffic such as low data rate traffic like VoIP and gaming over HSDPA.

To overcome this drawback 3GPP has introduced the concept of HS-SCCH less transmission for these kinds of low data rate traffic in Rel-7 specifications.

In HS-SCCH less mode operation, HS-SCCH is not transmitted for the initial transmission of data on HS-PDSCH. Therefore, UE will try to blindly decode the data on HS-PDSCH with predefined control information. If the UE is unable to blindly decode the initial transmission successfully then the data shall be retransmitted for a maximum of 2 times. During the retransmissions HS-SCCH is transmitted though. The HS-SCCH that is used for 1st and 2nd retransmission is called HS-SCCH Type 2. This is a new type of HS-SCCH that is defined for retransmitting data in HS-SCCH less mode operation.

Some of the benefits of HS-SCCH less mode operation are:

• Significant increase in VoIP capacity because of the reduction in overhead associated with HS-SCCH transmission

• Availability of HS-SCCH channel for other services because services like VoIP amongst others could be serviced without HS-SCCH

• The above two benefits translate into a large gain in the throughput available to the co-existing best effort's traffic at medium VoIP user loads

• More users can be code multiplexed in a single TTI for the delay sensitive traffic

Typical HS-SCCH Less Mode operation is illustrated is given below:

In HS-SCCH less mode operation, since HS-SCCH is not transmitted along with HS-PDSCH for the initial transmission the UE will use the following control information to demodulate and decode the data correctly.

• QPSK modulation is used. This is fixed for HS-SCCH less transmission. • A maximum of 2 channelisation codes that are adjacent to each other is used. The 1st

channelisation code (also called as code offset) is signalled to the UE in RRC Signalling Message. The 2nd channelisation code is derived by adding one to the code offset

• A maximum of 4 Transport Block Sizes are used. These TB Sizes are derived from the TB Size Indexes that are signalled to the UE in RRC signalling message. Note: see below for the difference in calculation of TB Size from TB Size Index in HS-SCCH less mode and non HS-SCCH less mode

• The redundancy and constellation version, also called as Xrv, to be used is fixed (pre-defined) to 0

• Since the initial transmission is with HS-SCCH less operation there is no need to indicate whether it is a new data or a retransmission

• 24 bit CRC (called as CRC attachment method 2) is coded in HS-PDSCH transmission with a UE specific identifier (H-RNTI)

For the initial HS-PDSCH transmission UE will not send NACK on HS-DPCCH if it is unable to decode the data. It will only ACK on HS-DPCCH if it is able to successfully decode the data. Because of the fixed timing relation between HS-PDSCH and HS-DPCCH i.e. a difference of 7.5 slots between the end of HS-PDSCH frame to the beginning of its corresponding HS-DPCCH frame (refer to section 7.7 of TS 25.211 v760) if the network does not detect an ACK for a HS-PDSCH transmission in HS-SCCH less mode then the network will think of it as a NACK and it will retransmit the data using HS-SCCH Type 2. The structure of HS-SCCH Type 2 is as given below (courtesy 3GPP TS 25.903), and it is used to transmit control information for the 1st and 2nd retransmissions:

• CCS (Channelisation Code Set) indicates the channelisation codes used for HS-PDSCH transmission. It can take values 1 or 2. 1 means channelisation code 1 and 2 means channelisation codes 1 and 2 are used for HS-PDSCH transmission

• 1 Bit (value 0) is used to indicate the QPSK modulation scheme • Format ID together with CCS is used to indicate to UE that it is HS-SCCH Type 2 • TB format (2 bits) is used to indicate one out of 4 Transport Block Sizes configured by higher layers.

This is one of the four values indicated to UE RRC in hs-scch-LessTFSI IE (see below in RRC ASN.1 IEs)

• Xrv = 3 and 4 for the 1st and 2nd retransmission respectively • reTx ID (1 bit) is used to indicate if it is a 1st or 2nd retransmission • Previous Tx Point (3 bits) is used to indicate the time of previous transmission in terms of offset from

the current TTI • 16 bit CRC (called as CRC attachment method 2) is coded with a UE specific identifier (H-RNTI)

In HS-SCCH less mode operation a UE shall be able to store 13 TTIs of data that could not be decoded. If the 1st retransmission using HS-SCCH Type2 could not be decoded then it will combine and store the 1st retransmission data with the initial HS-SCCH less transmission data in the cyclic buffer and this will be used again to decode the data associated with the 2nd retransmission. Therefore, "Previous Tx Point" of 3 bits given above is used to indicate the relative TTI position within the 13 TTIs of cyclic buffer to identify the data that needs to be used for combining and decoding the retransmission data. HS-SCCH less mode operation can be used only with MAC-hs entity in MAC layer. It cannot be used with MAC-ehs entity. MAC-ehs entity which will be described in the future posts. Virtual IR Buffer size (HARQ memory size) of at least 4536 bits should be configured in L1 HARQ when HS-SCCH less mode is configured. HS-SCCH less mode can only be configured if (Reference: section 8.5.35 of 25.331)

• UE is in Cell-DCH state • No DCH transport channels are configured • MIMO is not configured • Virtual IR buffer size (or alternatively called as HARQ memory size) of at least 4536 bits is configured

in HARQ

How to derive Transport Block Size from Transport Block Size Index in HS-SCCH less mode? The Transport Block size indicated by Transport Block size index is derived by taking the TB Size value corresponding to the index given by Transport Block size Index in the 1st table in Annexure A TS 25.321 v7b0. For example: if value 45 is indicated in hs-scch-LessTFSI IE then it would indicate a TB Size of 662 bits. Note: this is different to the way Transport Block size is calculated from the Transport Block size index in non HS-SCCH less mode. RRC ASN.1 IEs The following are the RRC ASN.1 IEs related to HS-SCCH Less Mode that will appear in Physical Channel information elements section of RRC downlink signalling messages like Radio Bearer Reconfiguration Messages: HS-SCCH-LessInfo-r7 ::= SEQUENCE { hs-scchLessOperation CHOICE { continue NULL, newOperation HS-SCCH-Less-NewOperation

} } HS-SCCH-Less-NewOperation ::= SEQUENCE { hs-pdsch-CodeIndex INTEGER (1..15), -- specifies the starting code of HS-PDSCH hs-scch-LessTFS HS-SCCH-LessTFSList } HS-SCCH-LessTFSList ::= SEQUENCE (SIZE (1..maxHS-SCCHLessTrBlk)) OF SEQUENCE { hs-scch-LessTFSI INTEGER (1..90), -- indicates the TFRI associated with the Transport Block size hs-scch-LessSecondCodeSupport BOOLEAN -- indicates the use of two consecutive HS-PDSCH codes when the TB size indicated by hs-scch-LessTFSI is used for HS-PDSCH transmission } References: TS 25.903, TS 25.212, TS 25.321 & TS 25.33

4. Continuous Packet Connectivity - HS-SCCH Orders

This is a continuation of explanation of the features in CPC (see my earlier post for a general description on CPC). HS-SCCH Order is another feature of CPC that can be used by the network to activate or deactivate the UL-DTX and/or DL-DRX by sending them as L1/PHY signalling commands to the UE. See my earliest post about the general description of CPC. For those of you who want to know what HS-SCCH is: HS-SCCH is a downlink physical channel that is used to carry downlink signalling relating to HS-DSCH transmission. HS-SCCH is a fixed rate (60 kbps, SF=128) channel. HS-SCCH orders are helpful in reducing the latency involved in Layer 3 (i.e. RRC) signaling. If the network were to signal at RRC level then RRC in RNC will send the message to UE RRC which in turn will configure UE L1. There is a significant delay involved in doing this. However, using HS-SCCH order PHY in Node-B will signal the PHY in UE to activate or deactivate UL-DTX and/or DL-DTX. This is particularly helpful in fast changing/deteriorating radio conditions where the Node-B can take quick decisions to activate/deactivate UL-DTX and/or DL-DRX. When HS-SCCH Order is transmitted there will be no associated HS-PDSCH transmission. The HS-SCCH channel structure used in HSDPA is as shown below. After the introduction of different HS-SCCH channel structures in Rel-7 the Rel-5 HS-SCCH, also called the legacy HS-SCCH, is called as HS-SCCH Type 1. For those of you who want to know the details about Rel-5 HS-SCCH structure can refer to the post: HS-SCCH Less Mode

The HS-SCCH Type 1 message structure is modified as below for HS-SCCH orders.

Instead of Channelisation Code Set (CCS), Modulation Scheme (MS) and Transport Block Size Index (TB Size) a fixed set of bits are transmitted in their respective positions. "Order Type" field will take a fixed value of "000" and "Order" field will take 3 bit values, say for example: x2 x1 x0 where x2 is the MSB; bits x2, x1 and x0 can take the following values.

When an HS-SCCH Order is transmitted to activate/deactivate UL-DTX then UE can apply the order following the timing given in the illustration given below:

Similarly when an HS-SCCH Order is transmitted to activate/deactivate DL-DRX then UE can apply the order following the timing given in the illustration given below:

References: TS 25.212, TS 25.214 & TS 25.211