3G/UMTS

DTX/DRX

DRX stands for "Discontinous Reception" and DTX stands for "Discontinous Transmission". When you are talking about 'Reception' and 'Transmission', you may often get confused with 'direction of data flow'. Is it from 'UE to Network' or 'Network to UE'. At least, I got confused so often with this.

So let's make it clear about 'who is receiving ?' and 'who is transmitting' when we are talking about DRX and DTX. The answer is 'UE'. Therefore, DRX means 'Discontinous Reception by UE' and DTX means 'Discontinous Transmission by UE'.

Then what does it mean by 'Discontinous' ? To get clear understanding of this word, let's think about 'what does it mean by 'continous' ?'.  'Continous' is a ordinary mode  of operation in most of the situation where we use mobile phone. Does 'Continous' mean that UE is continously (always) receiving some data and is continously (always) transmitting data ? No, it does not. UE cannot receive any data when Network does not send any data to it and UE cannot transmit any data when it does not have any data to send. 'Continuous transmission/Continuous Reception' in this context mean that 'UE is continuously (always) ready to recieve data and is continously (always) ready to transmit the data.

To be ready to recieve/transmit something, UE should be 'ON'. So Continous reception/Continous transmission means that "UE is always ON(Wake-up mode)".

What's wrong with UE being always 'ON'. You many easily figure out that it will cause a lot of battery consumption.

To save this kind of battery consumption, they invented a special mechanism called 'Discontinous Reception/Transmission'. 'Discontinous Transmission' and 'Discontinous Reception' means that UE is in Sleeping Mode most of the time and only periodically 'Wake up' to receive or transmit the data.

Overall concept would sound simple, but you may get confiused again trying to understand the detailed parameter related to DTX and DRX. These parameters are specified in Radio Bearer Message as follows.

First I thought we only need 'Periodicity of DTX/DRX' and 'Duration of ON time', but there are many other parameters are involved.

     | +-dtx-drx-TimingInfo ::= SEQUENCE OPTIONAL:Exist

     | | +-timing ::= CHOICE [newTiming]

     | |   +-newTiming ::= SEQUENCE

     | |     +-enablingDelay ::= ENUMERATED [radio-frames-0]

     | |     +-ue-dtx-drx-Offset ::= INTEGER (0..159) [0]

     | +-dtx-drx-Info ::= SEQUENCE [11] OPTIONAL:Exist

     | | +-dtx-Info ::= SEQUENCE [01] OPTIONAL:Exist

     | | | +-e-dch-TTI-Length ::= CHOICE [dtx-e-dch-TTI-10ms]

     | | | | +-dtx-e-dch-TTI-10ms ::= SEQUENCE

     | | | |   +-ue-dtx-Cycle1-10ms ::= ENUMERATED [sub-frames-10]

     | | | |   +-ue-dtx-Cycle2-10ms ::= ENUMERATED [sub-frames-20]

     | | | |   +-mac-dtx-Cycle-10ms ::= ENUMERATED [sub-frames-10]

     | | | +-ue-dtx-cycle2InactivityThreshold ::= ENUMERATED [e-dch-tti-8]

     | | | +-ue-dtx-cycle2DefaultSG ::= INTEGER OPTIONAL:Omit

     | | | +-ue-dtx-long-preamble-length ::= ENUMERATED [slots-4] OPTIONAL:Exist

     | | | +-mac-InactivityThreshold ::= ENUMERATED [e-dch-tti-8]

     | | | +-cqi-dtx-Timer ::= ENUMERATED [sub-frames-32]

     | | | +-ue-dpcch-Burst1 ::= ENUMERATED [sub-frames-1]

     | | | +-ue-dpcch-Burst2 ::= ENUMERATED [sub-frames-1]

     | | +-drx-Info ::= SEQUENCE OPTIONAL:Exist

     | | | +-ue-drx-Cycle ::= ENUMERATED [sub-frames-10]

     | | | +-ue-drx-Cycle-InactivityThreshold ::= ENUMERATED [sub-frames-32]

     | | | +-ue-GrantMonitoring-InactivityThreshold ::= ENUMERATED [e-dch-tti-8]

     | | | +-ue-drx-GrantMonitoring ::= BOOLEAN [TRUE]

     | | +-uplink-DPCCHSlotFormatInformation ::= ENUMERATED [slot-format-1]

Now let's look into the detailed parameters. Let's think about DTX part first. (I will draw some diagram later when I have more time, but now I will just describe it verbally). The most important parameters for DTX are as follows.

     | | | +-e-dch-TTI-Length ::= CHOICE [dtx-e-dch-TTI-10ms]

     | | | | +-dtx-e-dch-TTI-10ms ::= SEQUENCE

     | | | |   +-ue-dtx-Cycle1-10ms ::= ENUMERATED [sub-frames-10]

     | | | |   +-ue-dtx-Cycle2-10ms ::= ENUMERATED [sub-frames-20]

     | | | |   +-mac-dtx-Cycle-10ms ::= ENUMERATED [sub-frames-10]

First think about the cycles first. You see three different cycles here. In this example, we have the following three cycles.

ue-dtx-Cycle1-10ms ::= ENUMERATED [sub-frames-10] = 20 ms (2 ms/subframe x 10 subframe)

ue-dtx-Cycle2-10ms ::= ENUMERATED [sub-frames-20] = 40 ms (2 ms/subframe x 20 subframe)

mac-dtx-Cycle-10ms ::= ENUMERATED [sub-frames-10] = 20 ms(2 ms/subframe x 10 subframe)

The overall procedure of DTX operation goes as follows.

i) UE get's into sleeping mode and ue-dtx-Cycle1-10ms starts

ii) UE wake up when ue-dtx-Cycle1-10ms expires and stay up for a 'ON-duration'.

iii) If there is no E-DCH frame to be transmitted and ue-dtx-Cycle1-10ms is expired, it will get into sleeping mode and ue-dtx-Cycle2-10ms timer starts.

iv) UE wake up when ue-dtx-Cycle2-10ms timer expires and stay up for 'ON-duration'.

v) If there is no E-DCH frame to be transmitted and ue-dtx-Cycle1-10ms is expired, it will get into sleeping mode and ue-dtx-Cycle1-10ms timer starts.

vi) repeat the step step ii)~v).

The question is when UE wake up, how long it should stay 'up' ? In another words, how the 'ON time' is determined.

The 'ON time' is determined by e-dch-TTI-Length ::= CHOICE [dtx-e-dch-TTI-10ms]. In this example, the ON time is 10 ms.

One thing you notice is that ue-dtx-Cycle1-10ms and ue-dtx-Cycle2-10ms is alternating here.

In the procedure described above, we only mentioned about ue-dtx-Cycle1 and ue-dtx-Cycle2. Then what is the 'mac-DTX-Cycle' ? Simply put this is DTX cycle timer with the highest priority. In other words, even though UE would be in 'sleep mode' according to ue-dtx-Cycle1-10ms and ue-dtx-Cycle2-10ms, if it gets into 'ON period' of mac-dtx-Cycle-10ms, it should wake up right away and transmit the data.

Pretty complicated, right ? But it is even more complicated when it is really working on in real environment since we have to consider some additional factors as well. The only way for you to understand this is to collect as much example as possible to show you very diverse situation of DTX. Here goes one example, but I will keep adding more examples later.

Now let's look into DRX operation. The DRX cycle is specified as shown below. It seems a little bit simpler than DTX cycle configuration.

     | | +-drx-Info ::= SEQUENCE OPTIONAL:Exist

     | | | +-ue-drx-Cycle ::= ENUMERATED [sub-frames-10]

     | | | +-ue-drx-Cycle-InactivityThreshold ::= ENUMERATED [sub-frames-32]

The overall procedure is as follows.

i) UE gets into sleeping mode.

ii) UE wakes up when ue-drx-Cycle starts and stay up for one HS-PDSCH TTI.

iii.a) If there is no HS-PDSCH data for the UE during the 'ON time', it gets into sleeping mode.

iii.b) If there is HS-PDSCH data for the UE during the 'ON time', UE continue to stay on for the duration of ue-drx-Cycle-InactivityThreshold.

iii.c) if there is another HS-PDSCH data for the duration of of ue-drx-Cycle-InactivityThreshold, ON-time get extended for another ue-drx-Cycle-InactivityThreshold from the reception of the data.

iii.d) repeat step iii.a)~iii.c)

iv) repeat the steps ii)~iii)

You may think 'why UE need to go through such a complicated process described in the step iii ?'.  Logic is simple. If UE receives a data during the short period of 'ON-time', it is highly probably that there is another data coming right next TTI. So instead of getting into the sleeping mode right away just according to ue-drx-Cycle, it stay awake a little bit more not to cause too much delay for the downlink traffic.