I was googling for RRC state transitions in UMTS networks and found that "whenever UE feels that there is no data left for transmission it starts a timer T323 ,upon expiration of this timer it sends a SCRI signal to end connection. On reception of SCRI network decides the RRC state of UE."
I have some doubts in this procedure.
I am new to this field so please correct me, if i am wrong anywhere.
Sorry for my late response on this post...
Only now I realize there's a UMTS tag in StackOverflow... But I think I can help in some way.
First of all, let me answer your question. Then, I'll provide some details about it:
1. Does the value of T323 timer is fixed for a network or it changes with adaptability?
This timer is set by network. It has following possible values: 0,5,10,20,30,60,90,120 seconds.
I believe it does not change dynamically, but network can use different values in different region or cells.
2. Does transition from DCH to IDLE or DCH to PCH is possible in this model?
I might be wrong but I believe this is not possible.
SCRI is sent by the phone. Then, network move device to another state (either IDLE, CELL_PCH or URA_PCH). However, I believe that SCRI is usually sent when device is in CELL_FACH. So, phone goes to PCH only after FACH state (and not direclly from CELL_DCH).
3. In android device is there any way to know the timer T323 timeout value?
This timer is sent by network in System Information Block Type 1 message. This value is then, read and handle it by Mobile Baseband Processor (or Modem or CP - Communication Processor).
Usually, Fastdormancy feature is handled in Modem side and eventually, CP logs can print T323 value. However, CP Logs are not that easy to take in End-User phones. This kind of Logs are disabled on End-user software.
Of course, some company may want to handle FastDormancy feature in Application side and then, you would be able to check via log message. However, I think this is not the case...
Considerations about T323
This timer was created to block too many SCRI messages. This timer defines how much time Mobile Phone should wait to send two consecutive SCRI messages.
Below is the workflow: - Phone detects that no new packages will be sent to network. - Phone send first SCRI and start T323 timer. - Network move phone to CELL_PCH or URA_PCH. - Phone send some data and detects that no new data package will be sent soon. - It try to send SCRI again. However, if T323 is running, this SCRI is blocked. - After T323 expires, SCRI is free to be sent to network and whole process start again.
As you know, after SCRI message is sent, network moves phone to a low-power consumption state (Cell_PCH or URA_PCH). By doing this, some resources are released. If any new package need to be sent to network, phone must return to CELL_FACH/CELL_DCH and the resources must be restored. After send the data packages, phone will probably send SCRI again and all resource will be released again.
That's why T323 was created. To avoid resources to be released/restored very often. That behavior increases signal load in a cell because resources are releases/restored thru signalling messages.
How Mobile Phone Detect No New Package will be sent
This is totally a Mobile Phone Responsibility. So, every Mobile Phone brand has its own algorithm or feature to detect that a SCRI can be sent.
Of course, you can create complicated algorithms to predict when no more data-package will be sent and avoid send unecessary SCRI.
However, simpler solution has been applied. Usually, phone just wait sometime and if no data package was sent, it tries to send a SCRI message.
I hope I could help you someway.
T323 causes some confusion sometimes. But it only tells how much time phone should wait before send a new SCRI - after sending the first one.
It is set by network and when set to 0, phone does not wait to send SCRI. It can send whenever it want.
However, it is a mobile phone responsibility to decide when SCRI must be sent.
Fastdormancy aim to improve battery consumption by requesting to release resources as soon as no more packages will be sent.