3GPP Wireless Technology Demystified

Rel 7 UMTS - What is the need for MAC-ehs entity?

2010-04-30T11:44:00.000-07:00

In Rel-7 UMTS 3GPP have introduced a new MAC entity to support features like MIMO, 64QAM and so on. When there is a MAC-hs entity to support high speed (hs) data already what is the necessity for introducing another MAC entity. The reason is, the MAC-hs entity in Rel-5 did not support multiplexing of data from multiple reordering queues (also called as priority queues). Even though multiple logical channels can be mapped on multiple priority queues in MAC-hs entity, in a given TTI, data from only one priority queue can be transmitted. This may result in starvation of some bearers mapped on a lower priority queue if there is sufficient data to be transmitted in a higher priority queue.

In order to facilitate multiplexing of data from multiple priority queues and to support higher downlink transmission rates this MAC-ehs entity has been introduced. Regarding the problem related to starvation of some logical channels, introduction of MAC-ehs does not solve the problem of starvation algother. If the priority queues mapped on MAC-ehs are not given desired priority levels based on the QoS requirements of different bearers then the starvation on some logical channels can still occur.

This new MAC entity in the downlink also supports transmitting multiple (maximum of 2) MAC-ehs PDUs in a TTI. This is to support transmission of multiple streams in MIMO and Dual Carrier HSPA.

HSPA & eHSPA - Downlink Data Rates

2010-02-27T16:00:00.000-08:00

GSA report based on its November 2009 survey has predicted that the next baseline for broadband speed based on UMTS technology is going to be 21 Mbps in the downlink (i.e. from Node-B/Base Station to UE) whilst the current baseline is 14.4 Mbps. GSA survey statistics can be accessed from: Industry predicts 21 Mbps to be next mobile broadband baseline - GSA survey

When we speak about these every changing data rates I thought it is a good idea to give a summary of the data rates and highlight where the industry standard is heading towards. One such effort is the table given below. The table summarises the data rates for a given modulation and transmission technique used and the UMTS release they have been introduced in and their corresponding UE Categories. Please note that it does not state all the supported UE categories.

The below table has been derived based on Table 5.1a of TS 25.306 based on the UMTS Rel-9 specifications.

The data rates mentioned in the table is only indicative of theoretical data rates assuming ideal radio conditions. When I refer to ideal radio conditions I mean each user in a cell can be served to the maximum capacity. This is possible only if fewer users are in a cell and all of them are closer to the cell (not so for DC-HSPA though) so that the data can be transmitted with high power. As the number of data users increase the interference in the cell increases and consequently the average data rates the users can experience will also reduce. One should also note the amount of load the backhaul has to take to support high number of users with high data rates.

Last but not least, it goes without saying that other important features like CPC, Enhanced L2 and Enhanced Cell-FACH of Evolved HSPA (eHSPA) should also be employed to give enhanced user experience in wireless data access.

Wow! LTE is live...

2009-12-14T16:36:00.000-08:00

Did you hear that? Access to world first LTE service for as little as 10 pence to a maximum of 35 pence. It is too good to hear that but that is what, indeed, TeliaSonera have done in Oslo and Stockholm today. I am sure all the tech enthusiasts will pounce on such a very generous service offering. Don't be too excited on the pricing though.

Being a tech enthusiast and a guy who earns his bread on working on these technologies, I wish I could have been in Oslo or Stockholm to experience the thrill of first available LTE broadband speeds. I am not sure though how many can get their hands on these as, I believe, the number of subscribers may be limited, depending on the maximum capacity of the LTE cell(s).

Some facts about the data card:

The data card supports only LTE and, therefore, cannot move to any2G/3G cells.

The modem is supplied by Samsung and the Radio Access Network and Core Network are provided by Ericsson AB and Huawei Technologies for Stockholm and Oslo respectively.

Some facts about the pricing:

In Oslo it costs 1 Norwegian Kroner (10 pence) per month and the data card is free up to 1st July 2010. After that the price is going to be 699 Norwegian Kroner. There is a binding contract for 12 months though. Even then it is roughly coming to £37.5.

In Stockholm it costs 4 Swedish Kroner (35 pence) per month and the data card is free up to 1st July 2010. After that the price is going to be 599 Swedish Kroner. As in Oslo, there is a binding contract for 12 months. It roughly comes to £26. Hmm! nearly 10 quid cheaper than Oslo.

There is a limit of 30 GB per month and from 1st July 2010 onwards the current modems will be replaced for free by new modems that supports mobility to other 2G/3G cells.

For the guys in Stockholm and Oslo, enjoy the privilege of experiencing LTE speeds!

Look here for official TeliaSonera press release.

Importance of UMTS 900 MHz band (and lower bands) in changing economic environment

2009-10-14T15:29:00.000-07:00

Of late there has been quite a news about 900 MHz band. The 900 MHz band is getting more important now than ever before because of the spending squeeze the industry has been witnessing ever since the dawn of deep recession.

In the past 12 to 18 months I have heard whether HSPA+ is going to be embraced at all or not given that LTE has been making such huge strides. However, it is now clear from the reports (source GSA) that HSPA+ is going to be definitely embraced, probably not as a short gap approach but for relatively long time to come. In this context, it is also important to see how network operators can lower their costs for deployment of these technologies. That is where 900 MHz band comes into picture.

A case study of world's first successful rollout of UMTS900 band by Elisa Finland has been published by GSA on their website.

Similarly a case study of a successful rollout of UMTS900 band over a wide area by Optus network in Australia has also been published by GSA on their website.

These case studies can be accessed from: GSA Papers

Note: registration is required to access these documents.

In 3GPP specifications the UMTS 900 band is referred to as Band VIII and it uses 880-915 MHz in the uplink and 925-960 MHz for the downlink.

Highlights of UMTS900 band as compared to UMTS2100 band:

Radio propagation path loss is much lower in 900 MHz band because of the virtue of being a low frequency band.
Low radio propagation path loss results in better coverage and hence the number of sites (base stations/Node-B) required for similar coverage as provided by 2100 MHz band is significantly lower in 900 MHz.
The above point also results in significant CAPEX and OPEX savings. The statistics given above are extracted from the case studies of Optus network in Australia and Elisa Network in Finland. These benefits can be passed on to the end users.
It also gives better indoor coverage in urban areas resulting in better quality of service and customer satisfaction.
Because of the population density in rural areas it is a more viable option in business terms to use 900 MHz instead of 2100 MHz because of the ARPU and the cost of establishment of infrastructure.
Possibility of using the existing GSM900 infrastructure for faster rollout of UMTS900 network. This will also involve significant cost savings.

Similar to 900 MHz band other bands like 850 MHz are also being chosen by the operators to deploy HSPA and HSPA+ to have similar benefits as given above. The benefits involved reflects in the commitment to deploying UMTS 900 MHz band and HSPA(+) by network operators.

Interested readers can read more technical details about UMTS 900 MHz band at: UMTS Forum white paper

Further avid readers can go through an interesting market study of UMTS900 by Ovum Consulting @ UMTS900 Market Study

Enhanced Cell_FACH - HS-DSCH Channels in Cell_PCH State

2009-09-30T14:39:00.000-07:00

In the previous post I have given an introduction to Enhance Cell_FACH. In this post I will explain more about using high speed shared channels in Cell_PCH state to meet some of the objectives.

The main reason for keeping an UE in Cell_PCH state is to save battery power during periods of inactivity in the downlink. But if the downlink transmission starts again then transmission should start smoothly without any delay in setting up the channels. To accomplish this, HS-DSCH channels are made available in Cell_PCH state also.

In Cell_PCH state the BCCH, PCCH, DCCH and DTCH logical channels can be mapped on HS-DSCH in the downlink. BCCH is used to broadcast System Information, PCCH is used to wake up the UE with paging message (Paging Type 1), and DCCH & DTCH are used to resume the dedicated data and signalling transmission in the downlink without the need to setup channels.

An UE in Cell_PCH state is notified of changes to System Information by a "Paging Type 1" message on PCCH or "System Information Change Indication" message on BCCH (reception of System Information in "Enhanced Cell_FACH" is going to be described in a future post). Whereas to indicate activity on DCCH or DTCH, PICH (Paging Indicator Channel) is sent before transmitting the data on HS-SCCH/HS-PDSCH in Cell_PCH state (this is explained later). To achieve this new timing relationship between PICH and HS-SCCH is defined in Rel-7, and it is given below (courtesy 3GPP):

After the transmission of PICH the corresponding transmission of HS-SCCH will start after tpich chips. tpich is defined as 7680 chips i.e. 1 subframe.

In Cell_PCH state the feedback channel (HS-DPCCH) is unavailable. Therefore, the initial transmission at subframe#1 is followed by up to four immediately successive retransmissions. The number of retransmissions is configurable. The primary reason for doing blind retransmissions immediately following the initial transmissions is to increase the probability of UE reception because of absence of feedback channel in the uplink.

Retransmissions in Cell_PCH state with Common H-RNTI

The above illustration shows the retransmission mechanism in Cell_PCH state if the UE is assigned a Common H-RNTI. If a UE is assigned a Common H-RNTI then HS-PDSCH is transmitted without HS-SCCH (i.e. HS-SCCH Less transmission). Therefore, all the signalling information that is carried by HS-SCCH should be either fixed or semi-statically configured. The Xrv and modulation scheme to use is fixed whereas the HS-PDSCH channelisation code and the transport block sizes to use are semi-statically configured in RRC signalling message.

The number of retransmissions is configurable and up to 4 retransmissions can be configured. The new transmission at subframe 1 (CFN X+1) is transmitted with fixed Xrv value of 0, and the subsequent retransmissions are transmitted with fixed Xrv values of 2, 5, 6 and 1 for 1st, 2nd, 3rd and 4th retransmissions respectively. The modulation scheme is fixed to QPSK for all the (re)transmissions.

The number of retransmissions that immediately follow the initial transmission and the semi-static parameters described in the above paragraph are configurable. The UTRAN will indicate these in SIB 5 and SIB 5 Bis to the UE. The IE that will convey this information in SIB 5 and/or SIB 5 Bis is given below:

HS-DSCH-PagingSystemInformation ::= SEQUENCE {

dlScramblingCode SecondaryScramblingCode OPTIONAL, -- If absent same scrambling code as primary CPICH is used

pich-ForHSDPASupportedPagingList SEQUENCE (SIZE (1..maxSCCPCH)) OF PICH-ForHSDPASupportedPaging,

numberOfPcchTransmissions INTEGER(1..5),

transportBlockSizeList SEQUENCE (SIZE (1..2)) OF TransportBlockSizeIndex

}

PICH-ForHSDPASupportedPaging ::= SEQUENCE {

hsdpa-AssociatedPichInfo PICH-Info,

hs-pdschChannelisationCode INTEGER(1..15)

}

TransportBlockSizeIndex ::= INTEGER (1..32)

From the list of PICH channels that can be used for paging on HS-DSCH channels, given by pich-ForHSDPASupportedPagingList IE, UE will select the PICH to be used based on the following formula:

PICH Index = U-RNTI mod k

where k is the number of elements available in the pich-ForHSDPASupportedPagingList IE list and PICH index is the index in the pich-ForHSDPASupportedPagingList list.

From the index of PICH selected above take the corresponding hs-pdschChannelisationCode IE to determine the HS-PDSCH channelisation code to use. UE will try to blindly decode the data on HS-PDSCH with 2 transport block sizes given by transportBlockSizeList IE. The transport block size is calculated by taking the value pointed by TransportBlockSizeIndex in the 2nd table in Appendix A of TS 25.321 v7b0 i.e. the table that is used for MAC-ehs.

Retransmissions in Cell_PCH state with Dedicated H-RNTI

Let us see below how the retransmissions are going to be performed in Cell_PCH state when the UE is configured with a dedicated H-RNTI.

Unlike the HS-SCCH less transmission used when UE is configured with Common H-RNTI, HS-SCCH is transmitted with HS-PDSCH when UE is configured with a dedicated H-RNTI. Therefore, there is no need to fix the Xrv, modulation scheme, channelisation code and transport block sizes to use. All these are signalled on HS-SCCH. However, the number of retransmissions that follow the initial transmission is configurable in the same way as it is done when Common H-RNTI is configured.

How is the latency avoided for seamless data transmission in Cell_PCH state?

Having seen how the HS-DSCH channels are used in Cell_PCH state above let us understand how the latency is avoided for seamless data transmission in Cell_PCH state with an example. In order to service an "Always On" type of service based application like PoC let us consider that the UE is put in Cell_FACH state and is assigned a dedicated H-RNTI. If there are idle periods (i.e. periods where there are no transmissions in the downlink) the UTRAN can direct the UE to move to Cell_PCH state to conserve battery power. If the data transmission resumes on the downlink later the UTRAN can directly send the data on HS-DSCH in Cell_PCH state itself by indicating one frame before on PICH. This is illustrated in the figure given below:

This in constrast to pre Rel-7 Cell_PCH functionality is lot quicker as there is no need to do a Cell Update procedure to move back to Cell_FACH state, which is illustrated in the figure below.

As soon as the UE detects the data on HS-SCCH/HS-PDSCH with the dedicated H-RNTI the UE will move from Cell_PCH to Cell_FACH state and seamlessly continues with the data transmission. The user would not even notice this transition time from Cell_PCH to Cell_FACH.

References: 25.331, 25.321, 25.214

Continuous Packet Connectivity - Discontinuous Transmission (UL-DTX)

2009-08-26T14:06:00.000-07:00

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

Continuous Packet Connectivity - HS-SCCH Orders

2009-07-11T15:55:00.000-07:00

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

Continuous Packet Connectivity - HS-SCCH Less Mode

2009-06-22T16:33:00.000-07:00

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

Enhanced Cell_FACH - HS-DSCH Channels in Cell_FACH State

2009-06-03T14:01:00.000-07:00

In the previous 2 posts I have covered about the introduction of Enhanced Cell_FACH feature and the usage of HS-DSCH channels in Cell_PCH state. In this post I will explain about the use of HS-DSCH channels in Cell_FACH state.

In Cell_FACH state the BCCH, CCCH, DCCH and DTCH logical channels can be mapped on HS-DSCH in the downlink. Let us see below how these logical channels can be used with HS-DSCH channels.

UE in IDLE mode (typically when it is switched on) can:

Read System Information broadcasted in a cell
Establish a connection to the network to send or receive data on the uplink or downlink
Periodically update the network about its location (also called as "Location Update")

The UE will initially read the System Information broadcasted on PCCPCH/BCH/BCCH and will decide whether to camp on the cell or not. Once it camps on the cell the UE will also read the System Information that is required for making a connection to the network. Then UE will send a Connection Request message to the network on the RACH/PRACH. From that point onwards UE can use HS-DSCH channels (i.e. HS-DSCH mapped on HS-SCCH/HS-PDSCH) in the downlink to

read System Information on BCCH
send initially signalling messages on CCCH
send signalling messages and/or data in the downlink on DCCH/DTCH.

As stated in the above paragraph, when the UE reads the System Information on PCCPCH/BCH in IDLE mode it will extract the following information on SIB 5 and SIB 5 Bis messages for using HS-DSCH in the Cell_FACH state.

HS-DSCH-CommonSystemInformation ::= SEQUENCE {

ccch-MappingInfo CommonRBMappingInfo,

srb1-MappingInfo CommonRBMappingInfo OPTIONAL,

common-MAC-ehs-ReorderingQueueList Common-MAC-ehs-ReorderingQueueList,

hs-scch-SystemInfo HS-SCCH-SystemInfo,

harq-SystemInfo HARQ-Info,

common-H-RNTI-information SEQUENCE (SIZE (1..maxCommonHRNTI)) OF H-RNTI,

bcchSpecific-H-RNTI H-RNTI

}

As you probably would know, in order for the UE to decode HS-SCCH the UE needs an H-RNTI to determine if the downlink HS-DSCH transmission is designated for this UE or not. Therefore, for the UE to receive HS-DSCH in Cell_FACH state it would also need an H-RNTI. However, the H-RNTI that is used in Cell_FACH state is different to the H-RNTI that is used in Cell_DCH state. Since Cell_DCH is a dedicated state the H-RNTI that is used in Cell_DCH state is called Dedicated H-RNTI whereas the H-RNTI that is used to transit to Cell_FACH state from an IDLE state is called a Common H-RNTI because Cell_FACH state is a common state. One could ask here, what is the need for creating a different H-RNTI in Cell_FACH state. The reason is, if a dedicated H-RNTI were to be used in Cell_FACH state then it would put enormous amount of scheduling load on the Node-B to schedule HS-DSCH separately to each UE in the Cell. To address this issue, 3GPP has defined the use of an H-RNTI that can be used by all the UEs in a cell in common states, let alone Cell_FACH state. This H-RNTI is called Common H-RNTI and it can be used in both Cell_FACH and Cell_PCH states.

The UE will determine the Common H-RNTI to use in Cell_FACH state from common-H-RNTI-information IE received in SIB 5 or SIB 5 Bis. This IE is a list of Common H-RNTIs and the UE will choose the Common H-RNTI to use based on the following formula:

"Index of selected Common H-RNTI" = "Initial UE Identity" mod K

Where "Initial UE Identity" is the identity of the UE that is sent in "Connection Request" message and K is the number of Common H-RNTIs in the list of Common H-RNTIs given by the common-H-RNTI-information IE.

The above method to choose Common H-RNTI is used only if the UE is transitioning from IDLE to Cell_FACH state i.e. when the UE is not in Connected Mode. If the UE is in Connected Mode and if the UE has to use a Common H-RNTI in Cell_FACH state then the UE would use the following formula:

"Index of selected Common H-RNTI" = U-RNTI mod K

where U-RNTI is the UTRAN Radio Network Type Identifier that is assigned by the network to the UE after establishing a connection.

The UE will configure CCCH, MAC-ehs entity and its associated Reordering Queues as given by the HS-DSCH-CommonSystemInformation and ccch-MappingInfo IEs and will monitor HS-SCCH channels given by the hs-scch-SystemInfo IE. The UE will use the Common H-RNTI (calculated above) to decode the data on the monitored HS-SCCH channels.

If the network transmits "Connection Setup" message on the downlink CCCH mapped on HS-DSCH the UE decodes the message and forwards it to RRC layer. The RRC layer will check the UE Identity in the "Connection Setup" message and will determine if the message is designated for that UE or not. If the "Connection Setup" message is designated for this UE then UE will move into the target state given in the "Connection Setup" message. The UE will also store any H-RNTI (called as dedicated H-RNTI), if given, in the Connection Setup message. If the UE is assigned a dedicated H-RNTI then the UE will use that H-RNTI instead of the Common H-RNTI to decode the HS-DSCH transmission.

When is srb1-MappingInfo IE used?

If the UE moves from a dedicated state to a common state (for example Cell_DCH to Cell_FACH) because of a Radio Link Failure then the UE will do a Cell Update with cause Radio Link Failure on RACH/PRACH and will wait for response message on HS-DSCH to move to target state as directed by UTRAN. To receive the response for "Cell Update" (i.e. to receive "Cell Update Confirm" message) on the downlink the UE would also configure SRB1 (DCCH UM) based on the information given in srb1-MappingInfo IE. The "Cell Update Confirm" message could be sent on either SRB0 (CCCH) or SRB1 (DCCH). If it is sent on SRB1 then the UTRAN would also include U-RNTI in the MAC header (as given below). If the UE successfully decodes the HS-SCCH/HS-PDSCH with the Common H-RNTI (remember, U-RNTI would be used to select the Common H-RNTI as explained above) then UE will check the U-RNTI field in the MAC header (shown below) and then will decide if the downlink message is designated for that UE or not.

Having seen how HS-DSCH channels could be used in Cell_FACH state let us see the differences between using HS-DSCH channels in Cell_DCH and Cell_FACH state:

Random Access Channel is used in the uplink in Cell_FACH state whereas DCH/E-DCH is used in Cell_DCH state
HS-DPCCH (control channel to report result of downlink transmission decoding and channel quality) does not exist in Cell_FACH state whereas it exists in Cell_DCH state
Because of the above point, downlink channel quality in Cell_FACH state is reported in the form of "RACH Measurement Results" in Measurement Report or Cell Update messages on RACH
In Cell_DCH state retransmissions are based on what is reported on HS-DPCCH; whereas the retransmissions in Cell_FACH state are going to be blind retransmissions as there is no uplink HS-DPCCH to report the result of HS-DSCH decoding

How is AMC performed in Cell_FACH state?

The uplink control channel - HS-DPCCH, to report ACK/NACK/DTX and CQI (Channel Quality Indicator), does not exist in Cell_FACH state. Then one can ask the question how does AMC (Adaptive Modulation and Coding) scheme work in Cell_FACH state. Well, AMC is still supported in Cell_FACH although at a very slow rate. The reason why it is at a very slow rate is because UE will send the measured results of the downlink in Measurement Report or Cell Update messages to the RNC. Then RNC will report those results to Node-B in turn. Node-B will then try to perform AMC based on what it receives from RNC. This is illustrated in the figure below.

The above illustrated way of AMC operation is quite slow in comparison to the AMC operation done with HS-DPCCH because Node-B can perform AMC based on what it receives on HS-DPCCH. This is also illustrated below.

How to receive System Information on HS-DSCH?

UEs in Cell_FACH, Cell_PCH and URA_PCH states can receive BCCH on HS-DSCH. System Information that is broadcasted in a cell can be sent over BCCH mapped on HS-DSCH instead of BCCH mapped on BCH over PCCPCH.

Please note that UEs in IDLE mode cannot receive System Information on HS-DSCH.

The UE monitors the 1st HS-SCCH channel in the HS-SCCH channel list given by the hs-scch-SystemInfo IE and it would use bcchSpecific-H-RNTI of HS-DSCH-commonSystemInformation broadcasted in SIB 5 or SIB 5 Bis to decode HS-SCCH and its corresponding HS-PDSCH. The decoded data is forwarded to MAC. MAC will then check the LCH-ID field of MAC-ehs header to determine the logical channel the data is sent on. If the LCH-ID field is set to 15 (0xF), since BCCH specific H-RNTI is used to decode the data, the UE determines that data is sent on BCCH logical channel.

How to indicate the change in System Information to the UEs in Connected Mode?

For UEs in Cell_FACH state using HS-DSCH channels and for UEs in Cell_PCH or URA_PCH state with Dedicated H-RNTI configured UTRAN can send "System Information Change Indication" message on BCCH mapped on HS-DSCH to indicate the change in change in System Information. Either a modified value tag or an SFN is sent in "System Information Change Indication" to indicate when the System Information is going to change.

Whereas for UEs in Cell_PCH or URA_PCH states with no dedicated H-RNTIs configured the UTRAN can send Paging Type 1 message on PCCH mapped on HS-DSCH to indicate the change in System Information either through a modified value tag or through an SFN at which the modified System Information is going to be available at.

References: TS 25.331, TS 25.321 & TS 25.214

CETECOM selects Anritsu's HSPA Evolution Release 7 Protocol Conformance Test System

2009-05-12T11:33:00.000-07:00

CETECOM, the leading test house, has selected Anritsu's HSPA Evolution Release 7 Protocol Conformance Test System - ME7832A (model given in the picture below) as its conformance test solution for W-CDMA Release 7 features.

This shows the need for test solutions for Rel-7 (aka HSPA+ or HSPA Evolution) and the importance of Rel-7 and Rel-8 features of W-CDMA before the full transition to LTE.

This is also another indication that HSPA Evolution is here to stay for a while.

The official press release can be accessed at: http://www.eu.anritsu.com/news/default.php?id=668

For more information on ME7832A please refer to: http://www.eu.anritsu.com/products/default.php?p=379&model=ME7832A&name=Protocol%20Conformance%20Test%20System

Continuous Packet Connectivity - Discontinuous Reception (DL-DRX)

2009-05-06T15:44:00.000-07:00

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.

Femtocell Standard Published

2009-04-13T15:05:00.000-07:00

3GPP, Femto Forum and Broadband Forum have developed the worlds first femtocell standard. The standardisation of femtocells enables the operators to deploy the femtocells without worrying too much about the interoperability of femtocell nodes. Much anticipated Femtocell technology will address the indoor coverage issues that are currently plaguing the operators and users alike.

For more information go to the official press release.

Enhanced Cell_FACH in the Downlink - An Introduction

2009-04-07T15:00:00.000-07:00

Some of the biggest drawbacks in UMTS are the availability of less data rate on FACH (Forward Access Channel, also known as the common downlink channel) and the delay involved in the RRC state transition from common RRC states (Cell_FACH, Cell_PCH & URA_PCH) to dedicated RRC state (Cell_DCH).

To understand these further let us analyse the nature of some of the services that are provided on the transport provided by the UMTS Radio Protocols. In "always on" services like PoC (Push-to-talk over Cellular), Push e-mail and VPN Connections small packets of data (for example: keep alive packets) are transmitted frequently in the background. For such services FACH channels cannot be employed because a) the required peak data rate for such services cannot be supported by FACH, b) FACH does not support fast power control mechanism that is required for supporting high data rates and, c) if several users want to use such services in a cell then using FACH channel for so many users is far from ideal. So, instead of using FACH if DCH transport channels (which are dedicated to an user) are to be used then it is not preferred for these kind of services because it is waste of channel bandwidth and channelisation code space.

Let us consider one more example that explains the delay involved in RRC state transitions. If a mobile user is browsing the internet then most of the time there would not be any activity except for the times when the required content is to be downloaded or uploaded. In those kind of scenarios the mobile is directed by the network to be in Cell_PCH/URA_PCH state (semi-sleep mode) to conserve battery power. If the mobile user wants to again perform some activitiy (i.e. upload/download) when the UE is in semi-sleep mode then the UE has to perform a signalling procedure (Cell Update with an appropriate cause to inform the network of the latest cell in which the mobile is in and the reason for the Cell Update) with the network to again forward/download the data associated with the user request. Because of the latency involved in completing the required signalling the end-user would not perceive a good QoS (Quality of Service) hence degrading the overall end-user satisfaction.

To overcome the above deficiencies and to provide a good QoS that results in better end-user satisfaction 3GPP has introduced a new feature called "Enhanced Cell_FACH" in Rel-7 UMTS specifications that will use the high speed shared channels in RRC states other than Cell_DCH. Because high speed shared channels are used in all the connected mode RRC states the name "Enhanced Cell_FACH" is a bit of a misnomer in that sense.

Some of the advantages of using high speed shared channels in the downlink in RRC states other than Cell_DCH are:

HS-DSCH channels that are used in the downlink for achieving high data rates in HSDPA (Rel-5) can be used to prop up the available data rate as the network can use Adapative Modulation and Coding scheme to change the transmission parameters depending upon the network conditions although at a very slow rate because of unavailability of control channel in the uplink that will report the result of decoding at the UE and the radio conditions.
For the kind of services described above, if HS-DSCH channels are used in the downlink in all the RRC states then there is no need tear down and establish channels in the downlink and its assciated signalling.
In addition to the above the improvements done to high speed shared channels (HS-DSCH) as part of other Rel-7 features like Continuous Packet Connectivity (CPC) can also be taken advantage of.

Therefore, to summarise, some of the main goals of Enhanced Cell_FACH feature are to:

Increase the data rates in Cell_FACH state
Decrease the latency in RRC state switching
Better channelisation code usage
Use of shared channels in the downlink to take advantage of features like CPC and other Rel-7 features that use downlink shared channels
Align the radio protocol architecture of UMTS closer to the architecture used in LTE (Long Term Evolution) i.e. the use of shared channels in the uplink and downlink

Ok! enough of what Enhanced Cell_FACH can do to improve bla bla bla... Let us now look at the new mapping for logical channels, transport channels and physical channels in the downlink (in the below diagram). The indicator channels like PICH and MICH have been intentionally left out.

The red lines indicate the new mappings created for Enhanced Cell_FACH and the blue lines indicate the mapping of HS-DSCH that existed prior to introducing Enhanced Cell_FACH.

This is the first of many posts on Enhanced Cell_FACH. For the gory details on how it is going to work look forward to more posts on the same subject.

Continuous Packet Connectivity

2009-02-24T17:00:00.000-08:00

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.