Fast Dormancy in 3GPP

There are many way to waste UE battery power but there are some ways to save this rare and useful resource. Fast Dormancy is one of these. Fast dormancy was introduced in 3GPP release 8 of the specifications after that it was a huge hit among all the smart phone manufacturers. The basic principle behind Fast Dormancy is quite simple “Save phone power when it is inactive”.

Fast Dormancy Battery Life

So is it like before fast dormancy smartphone were draining all the power in no time? The answer is NO. Fast dormancy is a technical name 3GPP adapted. Before the standardisation many proprietary algorithms were used to solve this issue which some times termed as “Autonomous Signalling Connection Release”. This terminology may be differ between vendors. But the concepts are identical.

3GPP standards says that UE should send a “Signalling Connection Release Indication” to network with release cause set to “UE Requested PS Data session end”. This will terminate the signalling when UE is in absolute inactive state.

To know what is inactive state lets check out what UE (RRC) state are defined in 3GPP.

RRC Idle State

In Idle state no RRC connection exists and UE consumes the least power in this state. UE only transmits some signalling in rare occasions like “Location area update” and “Routing area update”. Apart from that UE monitors the Common Pilot Channel (CPICH) of the cell where it is camped. UE RRC connection is disconnected, so for doing some operation RRC connection is established.

PCH State

PCH state is similar to Idle (Not literally). The UE is RRC connected to UTRAN but no user data is sent. The biggest advantage of PCH is that UE does not need to establishing RRC connection when needed as RRC is in a connected state. UE can operate at very low power consumption, which is determined by the DRX cycles of the PCH states. In the following sections the PCH state could be either deployed by using Cell_PCH or URA_PCH or both.

CELL_PCH State

In CELL PCH UE need to inform UTRAN whenever it camps on a new cell which belongs to a different location area. In case when location area is changes UE need to move to do a cell update to move to CELL_FACH state for a limited period of time to sen CELL UPDATE message. UE listens to the same channels as idle and the radio wakes up every DRX cycle.

URA_PCH State

Similar to CELL PCH but updates are only sent when UTRAN Registration area is changes. As UTRAN registration area is a bigger geographical area so updates are sent less frequent than CELL_PCH state.

CELL_FACH State

In CELL FACH state UE is in connected mode using common or shared channels. This state is good for sending small amount of data. In uplink RACH (Random Access Channel) is used and in the downlink FACH (Foreword Access Channel) is used.

CELL DCH State

CELL DCH is the power consuming state. UE is connected using DCH (Dedicated Channel) or High Speed Shared Channel(HSDSCH) or Enhanced Dedicated Channel (EDCH). Only in CELL DCH state high volume of date packets are transmitted or received.

Here is an approximate comparison of battery power consumption in different states:

Idle = 1 (relative units)

Cell_PCH < 2 (this depends on the DRX ratio with Idle and the mobility)

URA_PCH ≤ Cell_PCH ( < in mobility scenarios, = in static scenarios)

Cell_FACH = 40 x Idle

Cell_DCH = 100 x Idle

How Fast Dormancy Works?

3GPP RRC was initially designed with CELL_PCH state and URA_PCH state to allow UEs to consume less power. But many networks are configured with relatively long inactivity timers for CELL_DCH, CELL_FACH states. So even for transmitting a small amount of data a lot of UE power is wasted.

There were many proprietary fast dormancy methods implemented before it’s standardised. In proprietary implementations UE sends a simulated Signalling Connection Release Indication to RNC. But the problem occurs when UE needs to set up signaling connection again. In some instances UE need to set up more than 25 connections in less than 5 minute period in commercial HSPA network, which is a lot of signaling traffic.

Fast Dormancy in 3GPP

In 3GPP release 8 fast dormancy was standardised. According to the standards UE can send Signalling Connection Release Indication to the network to show its intention for releasing the packet conniption but network is in care of the whole process. This is called network controlled fast dormancy.

The network sends a inhibit timer (T323) to UE in system information block type 1 (SIB1). Timer T323 tells how much time the UE need to wait before sending the next Signalling Connection Release Indication Message. The presence of T323 timer indicates that the network supports fast dormancy.

Release 8 fast dormancy is well described in WCDMA for UMTS: HSPA Evolution and LTE by Harri Holma and Antti Toskala. Also refer to 3GPP 25.331 (RRC) specification for more details.

LTE Vs HSPA+: Where is the future?

The history of mobile communication is long and an interesting one. Started back in 1950s the wireless technology evolved with time and requirements. The biggest technology breakthrough came as GSM (Global System for Mobile Communications, originally Groupe Spécial Mobile). GSM was basically developed for voice based communication and it was a near-perfect system for that purpose. But when data communication requirements came into picture GPRS (Global Packet Radio System) was introduced for better data throughput. They say Data Throughput is never enough.

3G-HSPA-LTE-Evolution

This simple concept of better data speed created 3G, which was quite good. Later from 3GPP release 5 HSDPA was introduced and in 3GPP release 6 HSUPA.

HSPA+

Then came HSPA+ which is basically enhancement to HSDPA and HSUPA. Most of the current network infrastructure supports downlink HSPA+ speed of 21 Mbps or 42 Mbps. The seed is good enough for current data hungry smart phones. But as I said earlier there is no upper limit to data rate.

HSPA-Advanced-Data-Throughput

HSPA+ enhances the mobile broadband experience by providing up to 28 Mbps peak data rates in the downlink (DL) in R7, and up to 42 Mbps in R8. HSPA+ has a strong evolution path and will continue to evolve beyond HSPA+ R8 to further enhance the HSPA+ performance and provide a clear evolution path for current HSPA networks. HSPA+ R9 and beyond is considering enhancements such as expanding HSPA+ multicarrier beyond 10 MHz deployments combined with MIMO (Multiple Input Multiple Output) to provide peak rates of 84 Mbps and more.

LTE

The next generation technology which was designed to take data communication to next level is LTE (Long Term Evolution). As LTE’s main requirement was to make a better technology for data communication LTE was made IP based, means instead of CS and PS plane (IUps and IUcs) now everything will be on one plane and that is only PS.

So how much data throughput one can expect from LTE?

Theoretical speeds boast downlink speeds of 300 Mbps and uploads of 75Mbps.

But that not enough!

Yes this is not the end as LTE is designed to evolve means it is easy to make changes and adopt to bring the best. As a result of that LTE-Advanced came into picture.

LTE-Advanced

LTE-Advanced can be considered as the real 4G technology (ITU). The throughput requirement for LTE-Advanced is set to 1 Gbps.

To accommodate LTE-Advanced capabilities, three new UE categories 6-8 have been defined. UE categories 1-5 for Release 8 and Release 9 were defined for LTE.

LTE-LTE-Advaned-Data-Rate-THroughput

Here is a road map for AT&T and it shows where AT&T is heading from network deployment prospective.

Here is the technology evolution path for HSPA+ and LTE. The LTE-Advanced 2016 (1 Gbps downlink) looks very interesting.

Conclusion

Although HSPA+ is the technology of today, LTE-Advanced will open many new doors for next generation smartphones and mobile equipments. The future is definitely with LTE and there is no doubt about that.

Do you think otherwise? Give your view.

Further Studies on LTE and HSPA+

There are numerous resources to improve your grip in LTE and HSPA+. For example 4G: LTE/LTE-Advanced for Mobile Broadband is a amazing book for LTE as well as LTE-Advanced research.

To get some strong understanding on HSPA+ try WCDMA for UMTS: HSPA Evolution and LTE authored by Harri Holma.

Soft & Softer Handover In UMTS System

What are soft and softer handover in 3G UMTS mobile system?

Handovers are an important part of every cellular communication system. They are used for providing mobility in cellular architectures. In UMTS systems different handover types have been introduced to cope also with other requirements as load control, coverage provisioning and offering quality of services.

Handover aims to provide continuity of mobile services to a user traveling over cell boundaries in a cellular infrastructure. For a user having an ongoing communication and crossing the cell edge, it is more favorable to use the radio resources in the new cell – also called the target cell because the signal strength perceived in the “old” cell worsens as the user penetrates the target cell.

The whole process of tearing down the existing connection in the current cell and establishing a new connection in the appropriate cell is called “handover”. The ability of a cellular network to perform efficient handovers is crucial to offer attractive services as real-time applications or streaming media as planned in third generation networks.

Especially in WCDMA two special types of handovers have been introduced; soft and softer handovers, allowing a mobile user to use 2 separate air interface channels when being in the overlapping area of two adjacent sectors.

Soft & Softer handovers are similar in techniques but there are some differences in both the techniques.

Softer Handover

Softer handover is the situation where one base station receives two user signals from two adjacent sectors it serves. In the case of softer handover the base station receives 2 separated signals through multi-path propagation. Due to reflections on buildings or natural barriers the signal sent from the mobile stations reaches the base station from two different sectors.

The signals received during softer handover are treated similarly as multi-path signals. In the uplink direction the signals received at the base station are routed to the same rake receiver and then combined following the maximum ratio combining technique. In the downlink direction the situation is slightly different as the base station uses different scrambling codes to separate the different sectors it serves.

So it is necessary for the different fingers of the rake receiver in the mobile terminal to apply the appropriate de-spreading code on the signals received from the different sectors before combining them together.

Soft Handover

In the case of soft handover the mobile station is in the overlapping cell coverage area of two sectors belonging to different base stations.

In downlink direction the signals received from the two different base stations are combined using MRC Rake processing in the mobile station.

In the uplink direction the received signals can no longer be combined in the base station but are routed to the RNC. The combining follows a different principle; in the RNC the two signals are compared on a frame-by-frame basis and the best candidate is selected after each interleaving period; i.e. every 10, 20, 40 or 80ms. As the outer loop power control algorithm measures the SNR of received uplink signals at a rate between 10 and 100Hz, this information is used to select the frame with the best quality during the soft handover.

The Soft Handover procedure is composed of a number of single functions:

  • Measurements
  • Filtering of Measurements
  • Reporting of Measurement results
  • The Soft Handover Algorithm
  • Execution of Handover

Soft Handover Algorithm

Soft handover in practice is a complex technique. The following example will describe soft handover for best case scenario.

Before describing the above scenario we need to know three important terms.

Active Set

User information is sent all the cell belongs to Active Set. In FDD, the cells in the active set are involved in soft handover. In TDD the active set always comprises one cell only. The UE shall only consider active set cells included in the variable CELL_INFO_LIST for measurement; i.e. active set cells not included in the CELL_INFO_LIST shall not be considered in any event evaluation and measurement reporting.

Monitored Set

Cells, which are not included in the active set, but are included in the CELL_INFO_LIST belong to the monitored set.

Detected Set

Cells detected by the UE, which are neither in the CELL_INFO_LIST nor in the active set belong to the detected set. Reporting of measurements of the detected set is only applicable to intra-frequency measurements made by UEs in CELL_DCH state.

The above scenario can be devided into three different parts.

Radio Link Addition (Event 1A)

Event 1A is triggered when a primary CPICH enters the reporting range. This means when a cell is strong enough to enter into Active Set.

Radio Link Deletion (Event 1B)

Event 1B is triggered when a primary CPICH leaves the reporting range. This happens when a cell in active set become weak and needs to be removed from Active Set.

Combined Radio Link Addition & Deletion (Event 1C)

Event 1C is triggered when a non-active primary CPICH becomes better than an active primary CPICH. When this event is triggered a primary CPICH is removed from the Active Set and a new stronger cell is added into Active Set.

You can get information on other events in another article.

Soft Handover Algorithm Flow Diagram

Further Studies

RRC Measurements Cheat Sheet

RRC Measurements Cheat Sheet (FDD) is a one page help guide. Cheat sheets are useful when debugging an issue or testing a test cases and you just need a quick look instead of going into the specification.

In this document we have recorded all the RRC measurements and the meaning of those events. Please let us know what you think about this.

If you have similar help sheet/cheat sheet which you have created and you want to share please send to us (contact@3glteinfo.com). We will publish those through 3glteinfo.


Download Here


RLC Bitmap Super Field (BITMAP-SUFI)


The BITMAP SUFI consists of the following fields:

  • Type identifier field(BITMAP)
  • LENGTH Filed
  • First Sequence Number(FSN)
  • Bitmap

The BITMAP SUFI fields in the STATUS PDU are as follows:

Type = BITMAP
LENGTH
FSN
Bitmap

LENGTH

The LENGTH is a 4 bits long field. The LENGTH field signifies the size of bitmap in octets.
The size of bitmap in octets = LENGTH + 1
So if, LENGTH = 0000 = 0
Size of bitmap = 0 + 1 = 1 octet

FSN

FSN is the sequence number of the first bit in the bitmap. FSN is 12 bits long.

Bitmap

In bitmap each bit position signifies whether FSN + bit_position is correctly received or not.

bit_position can have two different values:

1 Sequence Number = (FSN + bit_position) has been correctly received.
0 Sequence Number = (FSN + bit_position) has not been correctly received.

Example

Suppose the receiver needs to send the status of following PDUs to the transmitter.

Sequence Number of PDU Status
Sequence Number # 3 ACK
Sequence Number # 4 NACK
Sequence Number # 5 ACK
Sequence Number # 6 ACK
Sequence Number # 7 NACK
Sequence Number # 8 NACK
Sequence Number # 9 ACK
Sequence Number # 10 ACK

Step #1
The LENGTH = 0
LENGTH = 0000

Step #2
FSN = 3.
So the twelve bits FSN field will be encoded as:
FSN = 3 (%0000 0000 0011)

Step #3
LENGTH = 0
Bitmap = 1 octet
So the bitmap can be encoded as:

1 0 1 1 0 0 1 1

Step #4
The encoding of the Bitmap SUFI as follows:

0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 1
1 0 1 1 0 0 1 1
LENGTH
FSN
Bitmap

Reference


MAC-ehs PDU Structure with Example


There are two different types of MAC HSDPA PDU format depending upon the upper layer configuration.

  • MAC-hs
  • MAC-ehs

In this tutorial only MAC-ehs is covered.


In this case the MAC HSDPA PDU is consists of

  • MAC-ehs header
  • One or more reordering PDUs

Each reordering PDU consists of one or more reordering SDU belonging to the same priority queue.
Mac-ehs PDU Structure

Header Elements

LCH-ID (Logical Channel Identifier): 4 bits

The LCH-ID field provides identification of the logical channel at the receiver and the re-ordering buffer destination of a reordering SDU.

LCH-ID

Designation

0000

Logical Channel 1

0001

Logical Channel 2

. . . . . . .

. . . . . . . . . . . . . . . .

1110

Logical Channel 15

1111

Logical Channel 16

TSN (Transmission Sequence Number): 6 bits

The TSN field provides an identifier for the transmission sequence number on the HS-DSCH. The TSN field is used for reordering purposes to support in-sequence delivery to higher layers.

SI (Segmentation Indicator): 2 bits

The SI field indicates is MAC-ehs SDU has been segmented.

SI Field

Segmentation indication

00

The first reordering SDU of the reordering PDU is a completeMAC-ehs SDU.

The last reordering SDU of the reordering PDU is a complete MAC-ehs SDU.

01

If there are more than one reordering SDUs in the reordering PDU, the last reordering SDU of the reordering PDU is a complete MAC-ehs SDU.

The first reordering SDU of the reordering PDU is the last segment of a MAC-ehs SDU.

10

If there are more than one reordering SDUs in the reordering PDU, the first reordering SDU of the reordering PDU is a complete MAC-ehs SDU.

The last reordering SDU of the reordering PDU is the first segment of a MAC-ehs SDU.

11

If there are more than one reordering SDUs in the reordering PDU, the first reordering SDU of the reordering PDU is the last segment of a MAC-ehs SDU and the last reordering SDU of reordering PDU is the first segment of a MAC-ehs SDU.

If there is only one reordering SDU in the reordering PDU, the reordering SDU is a middle segment of a MAC-ehs SDU.

L (Length): 11 bits

The L field provides the length of the reordering SDU in octets. The reordering SDU size can vary for each reordering SDU in the MAC-ehs PDU, and is set for each reordering SDU individually.

F (Flag): 1 bit

The F field is a flag indicating if more fields are present in the MAC-ehs header or not.

  • 0: the F field is followed by an additional set of LCH-ID and L fields and optionally TSN and SI fields.
  • 1: the F field is followed by a reordering PDU. Each header extension corresponds to one reordering SDU.

Example in Decoding

e0 f4 11 80 06 01 10 10 a0 01 01 0d 59 06 11 5f ad d0 cb 6f 01 1c d6 21 10 a9 06 5f 0c 10 1f 50 f9 01 c1 11 91 22 d0 5c 66 c6 0a 50 a1 1a 00 1f 22 16 0a d0 b9 df f1 b1 19 02 11 fb 1c 20 21 12 c0 10 12 c9 00 1b 01 b1 00 bb 5a 1f 09 06 0c fd 0f b1 b6 9a 56 09 c1 aa 10 1d b6 10 1d 19 0f 92 1a 51 f2 61 d1 d5 10 bf 10 ba 1f 6f 5b 11 92 1d cb 09 d6 11 12 a1 11 00 2f c1 60 61 20 00 00

Header In Bits

1110 00001111010 000010 00 1

MAC-ehs PDU Header

LCH ID: 1110 (14)
L: 00001111010 (122)
TSN: 000010
SI: 00 (Complete Segment)
F: 1 (Reordering PDU Follows)

Reordering PDU :

0x80 06 01 10 10 a0 01 01 0d 59 06 11 5f ad d0 cb 6f 01 1c d6 21 10 a9 06 5f 0c 10 1f 50 f9 01 c1 11 91 22 d0 5c 66 c6 0a 50 a1 1a 00 1f 22 16 0a d0 b9 df f1 b1 19 02 11 fb 1c 20 21 12 c0 10 12 c9 00 1b 01 b1 00 bb 5a 1f 09 06 0c fd 0f b1 b6 9a 56 09 c1 aa 10 1d b6 10 1d 19 0f 92 1a 51 f2 61 d1 d5 10 bf 10 ba 1f 6f 5b 11 92 1d cb 09 d6 11 12 a1 11 00 2f c1 60 61 20

Padding : 0x

0000


Reference


MAC HSDPA PDU (MAC-hs)


There are two different types of MAC HSDPA PDU format depending upon the upper layer configuration.

  • MAC-hs
  • MAC-ehs

In this tutorial only MAC-hs is covered.


MAC-hs

In this case the MAC HSDPA PDU is consists of

  • MAC-hs header
  • One or more MAC-hs SDU

NOTE: A maximum of one HSDPA PDU is transmitted in on TTIMAC-hs PDU Format

Header Elements

  • VF (Version Flag): 1 bit

VF field is there to provide extension capabilities.
This should be set to zero for now

  • Queue ID (Queue Identifier): 3 bits
  • The Queue ID field provides identification of the reordering queue in the receiver.

  • TSN (Transmission Sequence Number): 6 bits or 9 bits
  • The TSN field provides an identifier for the transmission sequence number on the HS-DSCH. The TSN field is used for reordering purposes to support in-sequence delivery to higher layers.
    NOTE: Only for TDD 1.28 Mcps configuration TSN can have a value of 6 bits of 9 bits otherwise it is always 6 bits

  • SID (Size Index Identifier): 3 bits
  • The SID field identifies the size of a set of consecutive MAC-d PDUs. The MAC-d PDU size for a given SID is configured by higher layers and is independent for each Queue ID.

  • N (Number of MAC PDU): 7 bits
  • The number of consecutive MAC-d PDUs with equal size is identified with the N field.
    NOTE
    FDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 70.
    1.28 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 45.
    3.84 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 318
    7.68 Mcps TDD mode, the maximum number of PDUs transmitted in a single TTI shall be assumed to be 636.

  • F (Flag): 1bit
  • The F field is a flag indicating if more fields are present in the MAC-hs header or not.

    • If the F field is set to “0″ the F field is followed by an additional set of SID, N and F fields.
    • If the F field is set to “1″ the F field is followed by a MAC-d PDU.

    NOTE: The maximum number of MAC-hs header extensions, i.e. number of fields F set to “0″, in a single TTI shall be assumed to be 7.

    Example in decoding

    MAC-hs PDU

    0a 00 18 10 41 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03

    In Bits 0000 101000 000 0000001 1 000 – - –

    MAC-hs Header

    • VF: 0
    • Queue ID: 000
    • TSN: 000110
    • SID: 000
    • N: 0000001
    • F: 1

    Reference

    Medium Access Control (MAC) protocol specification:
    http://www.3gpp.org/ftp/Specs/archive/25_series/25.321/