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

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:

1. Radio propagation path loss is much lower in 900 MHz band because of the virtue of being a low frequency band.
2. 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.
3. 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.
4. It also gives better indoor coverage in urban areas resulting in better quality of service and customer satisfaction.
5. 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.
6. 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

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

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

Enhanced Cell_FACH - HS-DSCH Channels in Cell_FACH State

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:

1. Random Access Channel is used in the uplink in Cell_FACH state whereas DCH/E-DCH is used in Cell_DCH state
   
2. 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
   
3. 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
   
4. 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

Enhanced Cell_FACH - HS-DSCH Channels in Cell_PCH State

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

Femtocell Standard Published

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

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 - 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