Cell pch, FACH idle dilemma

**Mdaf** · 2013-06-25, 04:59 AM

I have a weird question.
We know that the cell FACH and PCH modes are meant to be for reducing signaling load and reducing setup time and to cope with bursty traffic related to data. and we know that when a UE in cell PCH or FACH it will make cell update on cell level as longs as the UE is moving.
My question assuming I'm having a UE in cell pch and it moved from cell A to cell B different node B and after finishing cell update procedure in cell B what are the resource from node B, air interface, iub resources that are reserved for the UE and are kept for the UE as long as the UE in cell pch or FACH?
Now if there are resources reserved for the UE while the ue in cell pch or FACH mode what will happen in case of new coming calls and there are congestion, and isn't this a waste of resources?
If there are no resources reserved so let's move all UEs in cell pch or FACH mode to save signaling and setup time and consider there's no such an idle mode (if its due to high number of cells update ok fine lets have URA pch and no idle). If you will tell me the common channel load I will say I'm talking about UEs in cell pch mode that almost doing nothing and waiting for the expiry time to go to idle and why do we send them to idle.
I hope you got my point of view.
So please tell me what I'm missing.

**Finetopix** · 2013-06-25 04:59 AM

**diegonavarrete** · 2013-06-25, 05:45 AM

The are not no reserved resources in nodeB baceuse they UE only listen the nodeB.
When you are in cell_fach mode and request for a PS service you are not get a DCH you will stay in cell_Fach mode.

**Mctest** · 2013-06-26, 12:54 AM

Originally Posted by diegonavarrete

The are not no reserved resources in nodeB baceuse they UE only listen the nodeB.
When you are in cell_fach mode and request for a PS service you are not get a DCH you will stay in cell_Fach mode.

Its wrong, channel switching switches you from rach/fach and dch resources will be allocated. And staying in fach eats your battery, because it decodes s-ccpch with sf64 continuously.